linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/7] Add the I3C subsystem
@ 2017-12-14 15:16 Boris Brezillon
  2017-12-14 15:16 ` [PATCH v2 1/7] i2c: Export of_i2c_get_board_info() Boris Brezillon
                   ` (7 more replies)
  0 siblings, 8 replies; 50+ messages in thread
From: Boris Brezillon @ 2017-12-14 15:16 UTC (permalink / raw)
  To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij,
	Boris Brezillon

This patch series is a proposal for a new I3C [1] subsystem.

This infrastructure is not complete yet and will be extended over
time.

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 still open to discussion. Please let me know if you think it's
  worth considering an asynchronous model here
- the bus element is a separate object and is not implicitly described
  by the master (as done in I2C). The reason is that I want to be able
  to handle multiple master connected to the same bus and visible to
  Linux.
  In this situation, we should only have one instance of the device and
  not one per master, and sharing the bus object would be part of the
  solution to gracefully handle this case.
  I'm not sure if we will ever need to deal with multiple masters
  controlling the same bus and exposed under Linux, but separating the
  bus and master concept is pretty easy, hence the decision to do it
  now, just in case we need it some day.
  The other benefit of separating the bus and master concepts is that
  master devices appear under the bus directory in sysfs.
- 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 busses 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 in this preliminary version:
- 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

Main changes between the initial RFC and this v2 are:
- Add a generic infrastructure to support IBIs. It's worth mentioning
  that I tried exposing IBIs as a regular IRQs, but after several
  attempts and a discussion with Mark Zyngier, it appeared that it was
  not really fitting in the Linux IRQ model (the fact that you have
  payload attached to IBIs, the fact that most of the time an IBI will
  generate a transfer on the bus which has to be done in an atomic
  context, ...)
  The counterpart of this decision is the latency induced by the
  workqueue approach, but since I don't have real use cases, I don't
  know if this can be a problem or not. 
- Add helpers to support Hot Join
- Add support for IBIs and Hot Join in Cadence I3C master driver
- Address several issues in how I was using the device model

I'll finish on a good news: this week the MIPI alliance opened the I3C
spec. So everyone can now review the patches (no need to be member of
the MIPI I3C group).
I'll let you find the link in the doc, this way maybe I'll have reviews
on the doc itself :-).

Thanks,

Boris

Boris Brezillon (7):
  i2c: Export of_i2c_get_board_info()
  i3c: Add core I3C infrastructure
  docs: driver-api: Add I3C documentation
  i3c: Add sysfs ABI spec
  dt-bindings: i3c: Document core bindings
  i3c: master: Add driver for Cadence IP
  dt-bindings: i3c: Document Cadence I3C master bindings

 Documentation/ABI/testing/sysfs-bus-i3c            |   95 ++
 .../devicetree/bindings/i3c/cdns,i3c-master.txt    |   45 +
 Documentation/devicetree/bindings/i3c/i3c.txt      |  128 ++
 Documentation/driver-api/i3c/conf.py               |   10 +
 Documentation/driver-api/i3c/device-driver-api.rst |    7 +
 Documentation/driver-api/i3c/index.rst             |    9 +
 Documentation/driver-api/i3c/master-driver-api.rst |    8 +
 Documentation/driver-api/i3c/protocol.rst          |  201 +++
 Documentation/driver-api/index.rst                 |    1 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +-
 drivers/i2c/i2c-core-base.c                        |    2 +-
 drivers/i2c/i2c-core-of.c                          |   66 +-
 drivers/i3c/Kconfig                                |   24 +
 drivers/i3c/Makefile                               |    4 +
 drivers/i3c/core.c                                 |  573 +++++++
 drivers/i3c/device.c                               |  344 ++++
 drivers/i3c/internals.h                            |   34 +
 drivers/i3c/master.c                               | 1433 ++++++++++++++++
 drivers/i3c/master/Kconfig                         |    5 +
 drivers/i3c/master/Makefile                        |    1 +
 drivers/i3c/master/i3c-master-cdns.c               | 1797 ++++++++++++++++++++
 include/linux/i2c.h                                |   10 +
 include/linux/i3c/ccc.h                            |  380 +++++
 include/linux/i3c/device.h                         |  321 ++++
 include/linux/i3c/master.h                         |  564 ++++++
 include/linux/mod_devicetable.h                    |   17 +
 27 files changed, 6053 insertions(+), 30 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c
 create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
 create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
 create mode 100644 Documentation/driver-api/i3c/conf.py
 create mode 100644 Documentation/driver-api/i3c/device-driver-api.rst
 create mode 100644 Documentation/driver-api/i3c/index.rst
 create mode 100644 Documentation/driver-api/i3c/master-driver-api.rst
 create mode 100644 Documentation/driver-api/i3c/protocol.rst
 create mode 100644 drivers/i3c/Kconfig
 create mode 100644 drivers/i3c/Makefile
 create mode 100644 drivers/i3c/core.c
 create mode 100644 drivers/i3c/device.c
 create mode 100644 drivers/i3c/internals.h
 create mode 100644 drivers/i3c/master.c
 create mode 100644 drivers/i3c/master/Kconfig
 create mode 100644 drivers/i3c/master/Makefile
 create mode 100644 drivers/i3c/master/i3c-master-cdns.c
 create mode 100644 include/linux/i3c/ccc.h
 create mode 100644 include/linux/i3c/device.h
 create mode 100644 include/linux/i3c/master.h

-- 
2.11.0

^ permalink raw reply	[flat|nested] 50+ messages in thread

* [PATCH v2 1/7] i2c: Export of_i2c_get_board_info()
  2017-12-14 15:16 [PATCH v2 0/7] Add the I3C subsystem Boris Brezillon
@ 2017-12-14 15:16 ` Boris Brezillon
  2017-12-14 15:16 ` [PATCH v2 2/7] i3c: Add core I3C infrastructure Boris Brezillon
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 50+ messages in thread
From: Boris Brezillon @ 2017-12-14 15:16 UTC (permalink / raw)
  To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij,
	Boris Brezillon

I3C busses have to know about all I2C devices connected on the I3C bus
to properly initialize the I3C master, and I2C frames can't be sent on
the bus until this initialization is done.

We can't let the I2C core parse the DT and instantiate I2C devices as
part of its i2c_add_adapter() procedure because, when done this way,
I2C devices are directly registered to the device-model and might be
attached to drivers which could in turn start sending frames on the bus,
which won't work since, as said above, the bus is not yet initialized.

Export of_i2c_register_device() in order to let the I3C core parse the
I2C device nodes by itself and initialize the bus.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Changes in v2:
- fix memset() call
- rebase on v4.15-rc1
---
 drivers/i2c/i2c-core-base.c |  2 +-
 drivers/i2c/i2c-core-of.c   | 66 ++++++++++++++++++++++++++-------------------
 include/linux/i2c.h         | 10 +++++++
 3 files changed, 49 insertions(+), 29 deletions(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 706164b4c5be..025df16e64be 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -774,7 +774,7 @@ i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
 	client->dev.parent = &client->adapter->dev;
 	client->dev.bus = &i2c_bus_type;
 	client->dev.type = &i2c_client_type;
-	client->dev.of_node = info->of_node;
+	client->dev.of_node = of_node_get(info->of_node);
 	client->dev.fwnode = info->fwnode;
 
 	i2c_dev_set_name(adap, client, info);
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index 8d474bb1dc15..7470bc418a3b 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -22,56 +22,66 @@
 
 #include "i2c-core.h"
 
-static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
-						 struct device_node *node)
+int of_i2c_get_board_info(struct device *dev, struct device_node *node,
+			  struct i2c_board_info *info)
 {
-	struct i2c_client *result;
-	struct i2c_board_info info = {};
-	struct dev_archdata dev_ad = {};
-	const __be32 *addr_be;
 	u32 addr;
-	int len;
+	int ret;
 
-	dev_dbg(&adap->dev, "of_i2c: register %pOF\n", node);
+	memset(info, 0, sizeof(*info));
 
-	if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
-		dev_err(&adap->dev, "of_i2c: modalias failure on %pOF\n",
-			node);
-		return ERR_PTR(-EINVAL);
+	if (of_modalias_node(node, info->type, sizeof(info->type)) < 0) {
+		dev_err(dev, "of_i2c: modalias failure on %pOF\n", node);
+		return -EINVAL;
 	}
 
-	addr_be = of_get_property(node, "reg", &len);
-	if (!addr_be || (len < sizeof(*addr_be))) {
-		dev_err(&adap->dev, "of_i2c: invalid reg on %pOF\n", node);
-		return ERR_PTR(-EINVAL);
+	ret = of_property_read_u32(node, "reg", &addr);
+	if (ret) {
+		dev_err(dev, "of_i2c: invalid reg on %pOF\n", node);
+		return ret;
 	}
 
-	addr = be32_to_cpup(addr_be);
 	if (addr & I2C_TEN_BIT_ADDRESS) {
 		addr &= ~I2C_TEN_BIT_ADDRESS;
-		info.flags |= I2C_CLIENT_TEN;
+		info->flags |= I2C_CLIENT_TEN;
 	}
 
 	if (addr & I2C_OWN_SLAVE_ADDRESS) {
 		addr &= ~I2C_OWN_SLAVE_ADDRESS;
-		info.flags |= I2C_CLIENT_SLAVE;
+		info->flags |= I2C_CLIENT_SLAVE;
 	}
 
-	if (i2c_check_addr_validity(addr, info.flags)) {
-		dev_err(&adap->dev, "of_i2c: invalid addr=%x on %pOF\n",
-			addr, node);
-		return ERR_PTR(-EINVAL);
+	ret = i2c_check_addr_validity(addr, info->flags);
+	if (ret) {
+		dev_err(dev, "of_i2c: invalid addr=%x on %pOF\n", addr, node);
+		return ret;
 	}
 
-	info.addr = addr;
-	info.of_node = of_node_get(node);
-	info.archdata = &dev_ad;
+	info->addr = addr;
+	info->of_node = node;
 
 	if (of_property_read_bool(node, "host-notify"))
-		info.flags |= I2C_CLIENT_HOST_NOTIFY;
+		info->flags |= I2C_CLIENT_HOST_NOTIFY;
 
 	if (of_get_property(node, "wakeup-source", NULL))
-		info.flags |= I2C_CLIENT_WAKE;
+		info->flags |= I2C_CLIENT_WAKE;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_i2c_get_board_info);
+
+static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
+						 struct device_node *node)
+{
+	struct i2c_client *result;
+	struct i2c_board_info info;
+	int ret;
+
+	dev_dbg(&adap->dev, "of_i2c: register %pOF\n", node);
+
+	ret = of_i2c_get_board_info(&adap->dev, node, &info);
+	if (ret)
+		return ERR_PTR(ret);
 
 	result = i2c_new_device(adap, &info);
 	if (result == NULL) {
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 0f774406fad0..666d458af0d2 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -809,6 +809,9 @@ extern const struct of_device_id
 *i2c_of_match_device(const struct of_device_id *matches,
 		     struct i2c_client *client);
 
+int of_i2c_get_board_info(struct device *dev, struct device_node *node,
+			  struct i2c_board_info *info);
+
 #else
 
 static inline struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
@@ -833,6 +836,13 @@ static inline const struct of_device_id
 	return NULL;
 }
 
+static inline int of_i2c_get_board_info(struct device *dev,
+					struct device_node *node,
+					struct i2c_board_info *info)
+{
+	return -ENOTSUPP;
+}
+
 #endif /* CONFIG_OF */
 
 #if IS_ENABLED(CONFIG_ACPI)
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2017-12-14 15:16 [PATCH v2 0/7] Add the I3C subsystem Boris Brezillon
  2017-12-14 15:16 ` [PATCH v2 1/7] i2c: Export of_i2c_get_board_info() Boris Brezillon
@ 2017-12-14 15:16 ` Boris Brezillon
  2017-12-17 22:32   ` Randy Dunlap
                     ` (3 more replies)
  2017-12-14 15:16 ` [PATCH v2 3/7] docs: driver-api: Add I3C documentation Boris Brezillon
                   ` (5 subsequent siblings)
  7 siblings, 4 replies; 50+ messages in thread
From: Boris Brezillon @ 2017-12-14 15:16 UTC (permalink / raw)
  To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij,
	Boris Brezillon

Add core infrastructure to support I3C in Linux and document it.

This infrastructure is not complete yet and will be extended over
time.

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 still open to discussion. Please let me know if you think
  it's worth considering an asynchronous model here
- the bus element is a separate object and is not implicitly described
  by the master (as done in I2C). The reason is that I want to be able
  to handle multiple master connected to the same bus and visible to
  Linux.
  In this situation, we should only have one instance of the device and
  not one per master, and sharing the bus object would be part of the
  solution to gracefully handle this case.
  I'm not sure we will ever need to deal with multiple masters
  controlling the same bus and exposed under Linux, but separating the
  bus and master concept is pretty easy, hence the decision to do it
  like that.
  The other benefit of separating the bus and master concepts is that
  master devices appear under the bus directory in sysfs.
- 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 busses 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 in this preliminary version:
- 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@free-electrons.com>
---
Changes in v2:
- Fix a bunch of mistake I made with the device model (pointed by GKH)
- Move the documentation out of this commit (pointed by GKH)
- only source drivers/i3c/master/Kconfig when CONFIG_I3C is enabled
  (pointed by GKH)
- Add IBI infrastructure
- Add helpers to ease support for Hot Join (most of the logic is
  delegated to I3C controller drivers)
- move the doc out of this commit to improve readability
- Fix a few bugs in device probing/remove (detected after trying to
  load/unload modules in various orders)
- Add a module_i3c_i2c_driver() macro to ease integration of drivers
  for devices that support both I3C and I2C mode
---
 drivers/Kconfig                 |    2 +
 drivers/Makefile                |    2 +-
 drivers/i3c/Kconfig             |   24 +
 drivers/i3c/Makefile            |    4 +
 drivers/i3c/core.c              |  573 ++++++++++++++++
 drivers/i3c/device.c            |  344 ++++++++++
 drivers/i3c/internals.h         |   34 +
 drivers/i3c/master.c            | 1433 +++++++++++++++++++++++++++++++++++++++
 drivers/i3c/master/Kconfig      |    0
 drivers/i3c/master/Makefile     |    0
 include/linux/i3c/ccc.h         |  380 +++++++++++
 include/linux/i3c/device.h      |  321 +++++++++
 include/linux/i3c/master.h      |  564 +++++++++++++++
 include/linux/mod_devicetable.h |   17 +
 14 files changed, 3697 insertions(+), 1 deletion(-)
 create mode 100644 drivers/i3c/Kconfig
 create mode 100644 drivers/i3c/Makefile
 create mode 100644 drivers/i3c/core.c
 create mode 100644 drivers/i3c/device.c
 create mode 100644 drivers/i3c/internals.h
 create mode 100644 drivers/i3c/master.c
 create mode 100644 drivers/i3c/master/Kconfig
 create mode 100644 drivers/i3c/master/Makefile
 create mode 100644 include/linux/i3c/ccc.h
 create mode 100644 include/linux/i3c/device.h
 create mode 100644 include/linux/i3c/master.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 152744c5ef0f..d7d78a812770 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -55,6 +55,8 @@ source "drivers/char/Kconfig"
 
 source "drivers/i2c/Kconfig"
 
+source "drivers/i3c/Kconfig"
+
 source "drivers/spi/Kconfig"
 
 source "drivers/spmi/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 1d034b680431..9790c8566918 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -112,7 +112,7 @@ obj-$(CONFIG_SERIO)		+= input/serio/
 obj-$(CONFIG_GAMEPORT)		+= input/gameport/
 obj-$(CONFIG_INPUT)		+= input/
 obj-$(CONFIG_RTC_LIB)		+= rtc/
-obj-y				+= i2c/ media/
+obj-y				+= i2c/ i3c/ media/
 obj-$(CONFIG_PPS)		+= pps/
 obj-y				+= ptp/
 obj-$(CONFIG_W1)		+= w1/
diff --git a/drivers/i3c/Kconfig b/drivers/i3c/Kconfig
new file mode 100644
index 000000000000..cf3752412ae9
--- /dev/null
+++ b/drivers/i3c/Kconfig
@@ -0,0 +1,24 @@
+# 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 design 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
diff --git a/drivers/i3c/Makefile b/drivers/i3c/Makefile
new file mode 100644
index 000000000000..3b6d1502d6e6
--- /dev/null
+++ b/drivers/i3c/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+i3c-y				:= core.o device.o master.o
+obj-$(CONFIG_I3C)		+= i3c.o
+obj-$(CONFIG_I3C)		+= master/
diff --git a/drivers/i3c/core.c b/drivers/i3c/core.c
new file mode 100644
index 000000000000..7eb8e84acd33
--- /dev/null
+++ b/drivers/i3c/core.c
@@ -0,0 +1,573 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ */
+
+#include <linux/idr.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/slab.h>
+
+#include "internals.h"
+
+static DEFINE_IDR(i3c_bus_idr);
+static DEFINE_MUTEX(i3c_core_lock);
+
+/**
+ * i3c_bus_maintenance_lock - Lock the bus for a maintenance operation
+ * @bus: I3C bus to take the lock on
+ *
+ * This function takes the bus lock so that no other operations can occur on
+ * the bus. This is needed for all kind of bus maintenance operation, like
+ * - enabling/disabling slave events
+ * - re-triggering DAA
+ * - changing the dynamic address of a device
+ * - relinquishing mastership
+ * - ...
+ *
+ * The reason for this kind of locking is that we don't want drivers and core
+ * logic to rely on I3C device information that could be changed behind their
+ * back.
+ */
+void i3c_bus_maintenance_lock(struct i3c_bus *bus)
+{
+	down_write(&bus->lock);
+}
+EXPORT_SYMBOL_GPL(i3c_bus_maintenance_lock);
+
+/**
+ * i3c_bus_maintenance_lock - Release the bus lock after a maintenance
+ *			      operation
+ * @bus: I3C bus to release the lock on
+ *
+ * Should be called when the bus maintenance operation is done. See
+ * i3c_bus_maintenance_lock() for more details on what these maintenance
+ * operations are.
+ */
+void i3c_bus_maintenance_unlock(struct i3c_bus *bus)
+{
+	up_write(&bus->lock);
+}
+EXPORT_SYMBOL_GPL(i3c_bus_maintenance_unlock);
+
+/**
+ * i3c_bus_normaluse_lock - Lock the bus for a normal operation
+ * @bus: I3C bus to take the lock on
+ *
+ * This function takes the bus lock for any operation that is not a maintenance
+ * operation (see i3c_bus_maintenance_lock() for a non-exhaustive list of
+ * maintenance operations). Basically all communications with I3C devices are
+ * normal operations (HDR, SDR transfers or CCC commands that do not change bus
+ * state or I3C dynamic address).
+ *
+ * Note that this lock is not guaranteeing serialization of normal operations.
+ * In other words, transfer requests passed to the I3C master can be submitted
+ * in parallel and I3C master drivers have to use their own locking to make
+ * sure two different communications are not inter-mixed, or access to the
+ * output/input queue is not done while the engine is busy.
+ */
+void i3c_bus_normaluse_lock(struct i3c_bus *bus)
+{
+	down_read(&bus->lock);
+}
+EXPORT_SYMBOL_GPL(i3c_bus_normaluse_lock);
+
+/**
+ * i3c_bus_normaluse_lock - Release the bus lock after a normal operation
+ * @bus: I3C bus to release the lock on
+ *
+ * Should be called when a normal operation is done. See
+ * i3c_bus_normaluse_lock() for more details on what these normal operations
+ * are.
+ */
+void i3c_bus_normaluse_unlock(struct i3c_bus *bus)
+{
+	up_read(&bus->lock);
+}
+EXPORT_SYMBOL_GPL(i3c_bus_normaluse_unlock);
+
+static ssize_t bcr_show(struct device *dev,
+			struct device_attribute *da,
+			char *buf)
+{
+	struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+	struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
+	ssize_t ret;
+
+	i3c_bus_normaluse_lock(bus);
+	ret = sprintf(buf, "%x\n", i3cdev->info.bcr);
+	i3c_bus_normaluse_unlock(bus);
+
+	return ret;
+}
+static DEVICE_ATTR_RO(bcr);
+
+static ssize_t dcr_show(struct device *dev,
+			struct device_attribute *da,
+			char *buf)
+{
+	struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+	struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
+	ssize_t ret;
+
+	i3c_bus_normaluse_lock(bus);
+	ret = sprintf(buf, "%x\n", i3cdev->info.dcr);
+	i3c_bus_normaluse_unlock(bus);
+
+	return ret;
+}
+static DEVICE_ATTR_RO(dcr);
+
+static ssize_t pid_show(struct device *dev,
+			struct device_attribute *da,
+			char *buf)
+{
+	struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+	struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
+	ssize_t ret;
+
+	i3c_bus_normaluse_lock(bus);
+	ret = sprintf(buf, "%llx\n", i3cdev->info.pid);
+	i3c_bus_normaluse_unlock(bus);
+
+	return ret;
+}
+static DEVICE_ATTR_RO(pid);
+
+static ssize_t address_show(struct device *dev,
+			    struct device_attribute *da,
+			    char *buf)
+{
+	struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+	struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
+	ssize_t ret;
+
+	i3c_bus_normaluse_lock(bus);
+	ret = sprintf(buf, "%02x\n", i3cdev->info.dyn_addr);
+	i3c_bus_normaluse_unlock(bus);
+
+	return ret;
+}
+static DEVICE_ATTR_RO(address);
+
+static const char * const hdrcap_strings[] = {
+	"hdr-ddr", "hdr-tsp", "hdr-tsl",
+};
+
+static ssize_t hdrcap_show(struct device *dev,
+			   struct device_attribute *da,
+			   char *buf)
+{
+	struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+	struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
+	unsigned long caps = i3cdev->info.hdr_cap;
+	ssize_t offset = 0, ret;
+	int mode;
+
+	i3c_bus_normaluse_lock(bus);
+	for_each_set_bit(mode, &caps, 8) {
+		if (mode >= ARRAY_SIZE(hdrcap_strings))
+			break;
+
+		if (!hdrcap_strings[mode])
+			continue;
+
+		ret = sprintf(buf + offset, offset ? " %s" : "%s",
+			      hdrcap_strings[mode]);
+		if (ret < 0)
+			goto out;
+
+		offset += ret;
+	}
+
+	ret = sprintf(buf + offset, "\n");
+	if (ret < 0)
+		goto out;
+
+	ret = offset + ret;
+
+out:
+	i3c_bus_normaluse_unlock(bus);
+
+	return ret;
+}
+static DEVICE_ATTR_RO(hdrcap);
+
+static struct attribute *i3c_device_attrs[] = {
+	&dev_attr_bcr.attr,
+	&dev_attr_dcr.attr,
+	&dev_attr_pid.attr,
+	&dev_attr_address.attr,
+	&dev_attr_hdrcap.attr,
+	NULL,
+};
+ATTRIBUTE_GROUPS(i3c_device);
+
+static int i3c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+	struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+	u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
+	u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
+	u16 ext = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
+
+	if (I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid))
+		return add_uevent_var(env, "MODALIAS=i3c:dcr%02Xmanuf%04X",
+				      i3cdev->info.dcr, manuf);
+
+	return add_uevent_var(env,
+			      "MODALIAS=i3c:dcr%02Xmanuf%04Xpart%04xext%04x",
+			      i3cdev->info.dcr, manuf, part, ext);
+}
+
+const struct device_type i3c_device_type = {
+	.groups	= i3c_device_groups,
+	.uevent = i3c_device_uevent,
+};
+
+const struct device_type i3c_master_type = {
+	.groups	= i3c_device_groups,
+};
+
+static int i3c_device_match(struct device *dev, struct device_driver *drv)
+{
+	struct i3c_device *i3cdev;
+	struct i3c_driver *i3cdrv;
+
+	if (dev->type != &i3c_device_type)
+		return 0;
+
+	i3cdev = dev_to_i3cdev(dev);
+	i3cdrv = drv_to_i3cdrv(drv);
+	if (i3c_device_match_id(i3cdev, i3cdrv->id_table))
+		return 1;
+
+	return 0;
+}
+
+static int i3c_device_probe(struct device *dev)
+{
+	struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+	struct i3c_driver *driver = drv_to_i3cdrv(dev->driver);
+
+	return driver->probe(i3cdev);
+}
+
+static int i3c_device_remove(struct device *dev)
+{
+	struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+	struct i3c_driver *driver = drv_to_i3cdrv(dev->driver);
+	int ret;
+
+	ret = driver->remove(i3cdev);
+	if (ret)
+		return ret;
+
+	if (WARN_ON(i3cdev->ibi))
+		i3c_device_free_ibi(i3cdev);
+
+	return ret;
+}
+
+struct bus_type i3c_bus_type = {
+	.name = "i3c",
+	.match = i3c_device_match,
+	.probe = i3c_device_probe,
+	.remove = i3c_device_remove,
+};
+
+enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus,
+						       u16 addr)
+{
+	int status, bitpos = addr * 2;
+
+	if (addr > I2C_MAX_ADDR)
+		return I3C_ADDR_SLOT_RSVD;
+
+	status = bus->addrslots[bitpos / BITS_PER_LONG];
+	status >>= bitpos % BITS_PER_LONG;
+
+	return status & I3C_ADDR_SLOT_STATUS_MASK;
+}
+
+void i3c_bus_set_addr_slot_status(struct i3c_bus *bus, u16 addr,
+				  enum i3c_addr_slot_status status)
+{
+	int bitpos = addr * 2;
+	unsigned long *ptr;
+
+	if (addr > I2C_MAX_ADDR)
+		return;
+
+	ptr = bus->addrslots + (bitpos / BITS_PER_LONG);
+	*ptr &= ~(I3C_ADDR_SLOT_STATUS_MASK << (bitpos % BITS_PER_LONG));
+	*ptr |= status << (bitpos % BITS_PER_LONG);
+}
+
+bool i3c_bus_dev_addr_is_avail(struct i3c_bus *bus, u8 addr)
+{
+	enum i3c_addr_slot_status status;
+
+	status = i3c_bus_get_addr_slot_status(bus, addr);
+
+	return status == I3C_ADDR_SLOT_FREE;
+}
+
+int i3c_bus_get_free_addr(struct i3c_bus *bus, u8 start_addr)
+{
+	enum i3c_addr_slot_status status;
+	u8 addr;
+
+	for (addr = start_addr; addr < I3C_MAX_ADDR; addr++) {
+		status = i3c_bus_get_addr_slot_status(bus, addr);
+		if (status == I3C_ADDR_SLOT_FREE)
+			return addr;
+	}
+
+	return -ENOMEM;
+}
+
+static void i3c_bus_init_addrslots(struct i3c_bus *bus)
+{
+	int i;
+
+	/* Addresses 0 to 7 are reserved. */
+	for (i = 0; i < 8; i++)
+		i3c_bus_set_addr_slot_status(bus, i, I3C_ADDR_SLOT_RSVD);
+
+	/*
+	 * Reserve broadcast address and all addresses that might collide
+	 * with the broadcast address when facing a single bit error.
+	 */
+	i3c_bus_set_addr_slot_status(bus, I3C_BROADCAST_ADDR,
+				     I3C_ADDR_SLOT_RSVD);
+	for (i = 0; i < 7; i++)
+		i3c_bus_set_addr_slot_status(bus, I3C_BROADCAST_ADDR ^ BIT(i),
+					     I3C_ADDR_SLOT_RSVD);
+}
+
+static const char * const i3c_bus_mode_strings[] = {
+	[I3C_BUS_MODE_PURE] = "pure",
+	[I3C_BUS_MODE_MIXED_FAST] = "mixed-fast",
+	[I3C_BUS_MODE_MIXED_SLOW] = "mixed-slow",
+};
+
+static ssize_t mode_show(struct device *dev,
+			 struct device_attribute *da,
+			 char *buf)
+{
+	struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
+	ssize_t ret;
+
+	i3c_bus_normaluse_lock(i3cbus);
+	if (i3cbus->mode < 0 ||
+	    i3cbus->mode > ARRAY_SIZE(i3c_bus_mode_strings) ||
+	    !i3c_bus_mode_strings[i3cbus->mode])
+		ret = sprintf(buf, "unknown\n");
+	else
+		ret = sprintf(buf, "%s\n", i3c_bus_mode_strings[i3cbus->mode]);
+	i3c_bus_normaluse_unlock(i3cbus);
+
+	return ret;
+}
+static DEVICE_ATTR_RO(mode);
+
+static ssize_t current_master_show(struct device *dev,
+				   struct device_attribute *da,
+				   char *buf)
+{
+	struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
+	ssize_t ret;
+
+	i3c_bus_normaluse_lock(i3cbus);
+	ret = sprintf(buf, "%s\n", dev_name(&i3cbus->cur_master->dev));
+	i3c_bus_normaluse_unlock(i3cbus);
+
+	return ret;
+}
+static DEVICE_ATTR_RO(current_master);
+
+static ssize_t i3c_scl_frequency_show(struct device *dev,
+				      struct device_attribute *da,
+				      char *buf)
+{
+	struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
+	ssize_t ret;
+
+	i3c_bus_normaluse_lock(i3cbus);
+	ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i3c);
+	i3c_bus_normaluse_unlock(i3cbus);
+
+	return ret;
+}
+static DEVICE_ATTR_RO(i3c_scl_frequency);
+
+static ssize_t i2c_scl_frequency_show(struct device *dev,
+				      struct device_attribute *da,
+				      char *buf)
+{
+	struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
+	ssize_t ret;
+
+	i3c_bus_normaluse_lock(i3cbus);
+	ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i2c);
+	i3c_bus_normaluse_unlock(i3cbus);
+
+	return ret;
+}
+static DEVICE_ATTR_RO(i2c_scl_frequency);
+
+static struct attribute *i3c_busdev_attrs[] = {
+	&dev_attr_mode.attr,
+	&dev_attr_current_master.attr,
+	&dev_attr_i3c_scl_frequency.attr,
+	&dev_attr_i2c_scl_frequency.attr,
+	NULL,
+};
+ATTRIBUTE_GROUPS(i3c_busdev);
+
+static void i3c_busdev_release(struct device *dev)
+{
+	struct i3c_bus *bus = container_of(dev, struct i3c_bus, dev);
+
+	while (!list_empty(&bus->devs.i2c)) {
+		struct i2c_device *i2cdev;
+
+		i2cdev = list_first_entry(&bus->devs.i2c, struct i2c_device,
+					  common.node);
+		list_del(&i2cdev->common.node);
+		of_node_put(i2cdev->info.of_node);
+		kfree(i2cdev);
+	}
+
+	while (!list_empty(&bus->devs.i3c)) {
+		struct i3c_device *i3cdev;
+
+		i3cdev = list_first_entry(&bus->devs.i3c, struct i3c_device,
+					  common.node);
+		list_del(&i3cdev->common.node);
+		put_device(&i3cdev->dev);
+	}
+
+	mutex_lock(&i3c_core_lock);
+	idr_remove(&i3c_bus_idr, bus->id);
+	mutex_unlock(&i3c_core_lock);
+
+	of_node_put(bus->dev.of_node);
+	kfree(bus);
+}
+
+static const struct device_type i3c_busdev_type = {
+	.groups	= i3c_busdev_groups,
+};
+
+void i3c_bus_unref(struct i3c_bus *bus)
+{
+	put_device(&bus->dev);
+}
+
+struct i3c_bus *i3c_bus_create(struct device *parent)
+{
+	struct i3c_bus *i3cbus;
+	int ret;
+
+	i3cbus = kzalloc(sizeof(*i3cbus), GFP_KERNEL);
+	if (!i3cbus)
+		return ERR_PTR(-ENOMEM);
+
+	init_rwsem(&i3cbus->lock);
+	INIT_LIST_HEAD(&i3cbus->devs.i2c);
+	INIT_LIST_HEAD(&i3cbus->devs.i3c);
+	i3c_bus_init_addrslots(i3cbus);
+	i3cbus->mode = I3C_BUS_MODE_PURE;
+	i3cbus->dev.parent = parent;
+	i3cbus->dev.of_node = of_node_get(parent->of_node);
+	i3cbus->dev.bus = &i3c_bus_type;
+	i3cbus->dev.type = &i3c_busdev_type;
+	i3cbus->dev.release = i3c_busdev_release;
+
+	mutex_lock(&i3c_core_lock);
+	ret = idr_alloc(&i3c_bus_idr, i3cbus, 0, 0, GFP_KERNEL);
+	mutex_unlock(&i3c_core_lock);
+	if (ret < 0)
+		goto err_free_bus;
+
+	i3cbus->id = ret;
+	device_initialize(&i3cbus->dev);
+
+	return i3cbus;
+
+err_free_bus:
+	kfree(i3cbus);
+
+	return ERR_PTR(ret);
+}
+
+void i3c_bus_unregister(struct i3c_bus *bus)
+{
+	device_unregister(&bus->dev);
+}
+
+int i3c_bus_register(struct i3c_bus *i3cbus)
+{
+	struct i2c_device *i2cdev;
+
+	i3c_bus_for_each_i2cdev(i3cbus, i2cdev) {
+		switch (i2cdev->lvr & I3C_LVR_I2C_INDEX_MASK) {
+		case I3C_LVR_I2C_INDEX(0):
+			if (i3cbus->mode < I3C_BUS_MODE_MIXED_FAST)
+				i3cbus->mode = I3C_BUS_MODE_MIXED_FAST;
+			break;
+
+		case I3C_LVR_I2C_INDEX(1):
+		case I3C_LVR_I2C_INDEX(2):
+			if (i3cbus->mode < I3C_BUS_MODE_MIXED_SLOW)
+				i3cbus->mode = I3C_BUS_MODE_MIXED_SLOW;
+			break;
+
+		default:
+			return -EINVAL;
+		}
+	}
+
+	if (!i3cbus->scl_rate.i3c)
+		i3cbus->scl_rate.i3c = I3C_BUS_TYP_I3C_SCL_RATE;
+
+	if (!i3cbus->scl_rate.i2c) {
+		if (i3cbus->mode == I3C_BUS_MODE_MIXED_SLOW)
+			i3cbus->scl_rate.i2c = I3C_BUS_I2C_FM_SCL_RATE;
+		else
+			i3cbus->scl_rate.i2c = I3C_BUS_I2C_FM_PLUS_SCL_RATE;
+	}
+
+	/*
+	 * I3C/I2C frequency may have been overridden, check that user-provided
+	 * values are not exceeding max possible frequency.
+	 */
+	if (i3cbus->scl_rate.i3c > I3C_BUS_MAX_I3C_SCL_RATE ||
+	    i3cbus->scl_rate.i2c > I3C_BUS_I2C_FM_PLUS_SCL_RATE) {
+		return -EINVAL;
+	}
+
+	dev_set_name(&i3cbus->dev, "i3c-%d", i3cbus->id);
+
+	return device_add(&i3cbus->dev);
+}
+
+static int __init i3c_init(void)
+{
+	return bus_register(&i3c_bus_type);
+}
+subsys_initcall(i3c_init);
+
+static void __exit i3c_exit(void)
+{
+	idr_destroy(&i3c_bus_idr);
+	bus_unregister(&i3c_bus_type);
+}
+module_exit(i3c_exit);
+
+MODULE_AUTHOR("Boris Brezillon <boris.brezillon@free-electrons.com>");
+MODULE_DESCRIPTION("I3C core");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/i3c/device.c b/drivers/i3c/device.c
new file mode 100644
index 000000000000..dcf51150b7cb
--- /dev/null
+++ b/drivers/i3c/device.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ */
+
+#include <linux/slab.h>
+
+#include "internals.h"
+
+/**
+ * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a
+ *				specific device
+ *
+ * @dev: device with which the transfers should be done
+ * @xfers: array of transfers
+ * @nxfers: number of transfers
+ *
+ * Initiate one or several private SDR transfers with @dev.
+ *
+ * This function can sleep and thus cannot be called in atomic context.
+ *
+ * Return: 0 in case of success, a negative error core otherwise.
+ */
+int i3c_device_do_priv_xfers(struct i3c_device *dev,
+			     struct i3c_priv_xfer *xfers,
+			     int nxfers)
+{
+	struct i3c_master_controller *master;
+	int i, ret;
+
+	master = i3c_device_get_master(dev);
+	if (!master)
+		return -EINVAL;
+
+	i3c_bus_normaluse_lock(master->bus);
+	for (i = 0; i < nxfers; i++)
+		xfers[i].addr = dev->info.dyn_addr;
+
+	ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
+	i3c_bus_normaluse_unlock(master->bus);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);
+
+/**
+ * i3c_device_send_hdr_cmds() - send HDR commands to a specific device
+ *
+ * @dev: device to which these commands should be sent
+ * @cmds: array of commands
+ * @ncmds: number of commands
+ *
+ * Send one or several HDR commands to @dev.
+ *
+ * This function can sleep and thus cannot be called in atomic context.
+ *
+ * Return: 0 in case of success, a negative error core otherwise.
+ */
+int i3c_device_send_hdr_cmds(struct i3c_device *dev,
+			     struct i3c_hdr_cmd *cmds,
+			     int ncmds)
+{
+	struct i3c_master_controller *master;
+	enum i3c_hdr_mode mode;
+	int ret, i;
+
+	if (ncmds < 1)
+		return 0;
+
+	mode = cmds[0].mode;
+	for (i = 1; i < ncmds; i++) {
+		if (mode != cmds[i].mode)
+			return -EINVAL;
+	}
+
+	master = i3c_device_get_master(dev);
+	if (!master)
+		return -EINVAL;
+
+	i3c_bus_normaluse_lock(master->bus);
+	for (i = 0; i < ncmds; i++)
+		cmds[i].addr = dev->info.dyn_addr;
+
+	ret = i3c_master_send_hdr_cmds_locked(master, cmds, ncmds);
+	i3c_bus_normaluse_unlock(master->bus);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_device_send_hdr_cmds);
+
+void i3c_device_get_info(struct i3c_device *dev,
+			 struct i3c_device_info *info)
+{
+	if (info)
+		*info = dev->info;
+}
+EXPORT_SYMBOL_GPL(i3c_device_get_info);
+
+/**
+ * i3c_device_disable_ibi() - Disable IBIs coming from a specific device
+ * @dev: device on which IBIs should be disabled
+ *
+ * This function disable IBIs coming from a specific device and wait for
+ * all pending IBIs to be processed.
+ *
+ * Return: 0 in case of success, a negative error core otherwise.
+ */
+int i3c_device_disable_ibi(struct i3c_device *dev)
+{
+	struct i3c_master_controller *master = i3c_device_get_master(dev);
+	int ret;
+
+	mutex_lock(&dev->ibi_lock);
+	if (!dev->ibi) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	ret = master->ops->disable_ibi(master, dev);
+	if (ret)
+		goto out;
+
+	reinit_completion(&dev->ibi->all_ibis_handled);
+	if (atomic_read(&dev->ibi->pending_ibis))
+		wait_for_completion(&dev->ibi->all_ibis_handled);
+
+	dev->ibi->enabled = false;
+
+out:
+	mutex_unlock(&dev->ibi_lock);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(i3c_device_disable_ibi);
+
+/**
+ * i3c_device_enable_ibi() - Enable IBIs coming from a specific device
+ * @dev: device on which IBIs should be enabled
+ *
+ * This function enable IBIs coming from a specific device and wait for
+ * all pending IBIs to be processed. This should be called on a device
+ * where i3c_device_request_ibi() has succeeded.
+ *
+ * Note that IBIs from this device might be received before this function
+ * returns to its caller.
+ *
+ * Return: 0 in case of success, a negative error core otherwise.
+ */
+int i3c_device_enable_ibi(struct i3c_device *dev)
+{
+	struct i3c_master_controller *master = i3c_device_get_master(dev);
+	int ret;
+
+	mutex_lock(&dev->ibi_lock);
+	if (!dev->ibi) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	ret = master->ops->enable_ibi(master, dev);
+	if (!ret)
+		dev->ibi->enabled = true;
+
+out:
+	mutex_unlock(&dev->ibi_lock);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_device_enable_ibi);
+
+/**
+ * i3c_device_request_ibi() - Request an IBI
+ * @dev: device for which we should enable IBIs
+ * @req: setup requested for this IBI
+ *
+ * This function is responsible for pre-allocating all resources needed to
+ * process IBIs coming from @dev. When this function returns, the IBI is not
+ * enabled until i3c_device_enable_ibi() is called.
+ *
+ * Return: 0 in case of success, a negative error core otherwise.
+ */
+int i3c_device_request_ibi(struct i3c_device *dev,
+			   const struct i3c_ibi_setup *req)
+{
+	struct i3c_master_controller *master = dev->common.master;
+	struct i3c_device_ibi_info *ibi;
+	int ret;
+
+	if (!master->ops->request_ibi)
+		return -ENOTSUPP;
+
+	if (!req->handler || !req->num_slots)
+		return -EINVAL;
+
+	mutex_lock(&dev->ibi_lock);
+	if (dev->ibi) {
+		ret = -EBUSY;
+		goto err_unlock_dev;
+	}
+
+	ibi = kzalloc(sizeof(*ibi), GFP_KERNEL);
+	if (!ibi) {
+		ret = -ENOMEM;
+		goto err_unlock_dev;
+	}
+
+	atomic_set(&ibi->pending_ibis, 0);
+	init_completion(&ibi->all_ibis_handled);
+	ibi->handler = req->handler;
+	ibi->max_payload_len = req->max_payload_len;
+
+	dev->ibi = ibi;
+	ret = master->ops->request_ibi(master, dev, req);
+	if (ret)
+		goto err_free_ibi;
+
+	mutex_unlock(&dev->ibi_lock);
+
+	return 0;
+
+err_free_ibi:
+	mutex_unlock(&dev->ibi_lock);
+	kfree(ibi);
+	dev->ibi = NULL;
+
+err_unlock_dev:
+	mutex_unlock(&dev->ibi_lock);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_device_request_ibi);
+
+/**
+ * i3c_device_free_ibi() - Free all resources needed for IBI handling
+ * @dev: device on which you want to release IBI resources
+ *
+ * This function is responsible for de-allocating resources previously
+ * allocated by i3c_device_request_ibi(). It should be called after disabling
+ * IBIs with i3c_device_disable_ibi().
+ */
+void i3c_device_free_ibi(struct i3c_device *dev)
+{
+	struct i3c_master_controller *master = dev->common.master;
+
+	mutex_lock(&dev->ibi_lock);
+	if (!dev->ibi)
+		goto out;
+
+	if (WARN_ON(dev->ibi->enabled))
+		BUG_ON(i3c_device_disable_ibi(dev));
+
+	master->ops->free_ibi(master, dev);
+	kfree(dev->ibi);
+	dev->ibi = NULL;
+
+out:
+	mutex_unlock(&dev->ibi_lock);
+}
+EXPORT_SYMBOL_GPL(i3c_device_free_ibi);
+
+/**
+ * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
+ * @i3cdev: the I3C device we're searching a match for
+ * @id_table: the I3C device ID table
+ *
+ * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
+ *	   no match.
+ */
+const struct i3c_device_id *
+i3c_device_match_id(struct i3c_device *i3cdev,
+		    const struct i3c_device_id *id_table)
+{
+	const struct i3c_device_id *id;
+
+	/*
+	 * The lower 32bits of the provisional ID is just filled with a random
+	 * value, try to match using DCR info.
+	 */
+	if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
+		u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
+		u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
+		u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
+
+		/* First try to match by manufacturer/part ID. */
+		for (id = id_table; id->match_flags != 0; id++) {
+			if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
+			    I3C_MATCH_MANUF_AND_PART)
+				continue;
+
+			if (manuf != id->manuf_id || part != id->part_id)
+				continue;
+
+			if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
+			    ext_info != id->extra_info)
+				continue;
+
+			return id;
+		}
+	}
+
+	/* Fallback to DCR match. */
+	for (id = id_table; id->match_flags != 0; id++) {
+		if ((id->match_flags & I3C_MATCH_DCR) &&
+		    id->dcr == i3cdev->info.dcr)
+			return id;
+	}
+
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(i3c_device_match_id);
+
+/**
+ * i3c_driver_register_with_owner() - register an I3C device driver
+ *
+ * @drv: driver to register
+ * @owner: module that owns this driver
+ *
+ * Register @drv to the core.
+ *
+ * Return: 0 in case of success, a negative error core otherwise.
+ */
+int i3c_driver_register_with_owner(struct i3c_driver *drv, struct module *owner)
+{
+	drv->driver.owner = owner;
+	drv->driver.bus = &i3c_bus_type;
+
+	return driver_register(&drv->driver);
+}
+EXPORT_SYMBOL_GPL(i3c_driver_register_with_owner);
+
+/**
+ * i3c_driver_unregister() - unregister an I3C device driver
+ *
+ * @drv: driver to unregister
+ *
+ * Unregister @drv.
+ */
+void i3c_driver_unregister(struct i3c_driver *drv)
+{
+	driver_unregister(&drv->driver);
+}
+EXPORT_SYMBOL_GPL(i3c_driver_unregister);
diff --git a/drivers/i3c/internals.h b/drivers/i3c/internals.h
new file mode 100644
index 000000000000..798367b318cf
--- /dev/null
+++ b/drivers/i3c/internals.h
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ */
+
+#ifndef I3C_INTERNALS_H
+#define I3C_INTERNALS_H
+
+#include <linux/i3c/master.h>
+
+extern struct bus_type i3c_bus_type;
+extern const struct device_type i3c_master_type;
+extern const struct device_type i3c_device_type;
+
+void i3c_bus_unref(struct i3c_bus *bus);
+struct i3c_bus *i3c_bus_create(struct device *parent);
+void i3c_bus_unregister(struct i3c_bus *bus);
+int i3c_bus_register(struct i3c_bus *i3cbus);
+int i3c_bus_get_free_addr(struct i3c_bus *bus, u8 start_addr);
+bool i3c_bus_dev_addr_is_avail(struct i3c_bus *bus, u8 addr);
+void i3c_bus_set_addr_slot_status(struct i3c_bus *bus, u16 addr,
+				  enum i3c_addr_slot_status status);
+enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus,
+						       u16 addr);
+
+int i3c_master_do_priv_xfers_locked(struct i3c_master_controller *master,
+				    const struct i3c_priv_xfer *xfers,
+				    int nxfers);
+int i3c_master_send_hdr_cmds_locked(struct i3c_master_controller *master,
+				    const struct i3c_hdr_cmd *cmds, int ncmds);
+
+#endif /* I3C_INTERNAL_H */
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
new file mode 100644
index 000000000000..1c85abac08d5
--- /dev/null
+++ b/drivers/i3c/master.c
@@ -0,0 +1,1433 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ */
+
+#include <linux/slab.h>
+
+#include "internals.h"
+
+static inline struct i3c_master_controller *
+i2c_adapter_to_i3c_master(struct i2c_adapter *adap)
+{
+	return container_of(adap, struct i3c_master_controller, i2c);
+}
+
+static inline struct i2c_adapter *
+i3c_master_to_i2c_adapter(struct i3c_master_controller *master)
+{
+	return &master->i2c;
+}
+
+static void i3c_i2c_dev_init(struct i3c_master_controller *master,
+			     struct i3c_i2c_dev *dev, bool i2cdev)
+{
+	dev->bus = master->bus;
+	dev->master = master;
+}
+
+static struct i2c_device *
+i3c_master_alloc_i2c_dev(struct i3c_master_controller *master,
+			 const struct i2c_board_info *info, u8 lvr)
+{
+	struct i2c_device *dev;
+
+	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+	if (!dev)
+		return ERR_PTR(-ENOMEM);
+
+	i3c_i2c_dev_init(master, &dev->common, true);
+	dev->info = *info;
+	dev->lvr = lvr;
+	dev->info.of_node = of_node_get(info->of_node);
+	i3c_bus_set_addr_slot_status(master->bus, info->addr,
+				     I3C_ADDR_SLOT_I2C_DEV);
+
+	return dev;
+}
+
+static int i3c_master_send_ccc_cmd_locked(struct i3c_master_controller *master,
+					  struct i3c_ccc_cmd *cmd)
+{
+	if (WARN_ON(!rwsem_is_locked(&master->bus->lock)))
+		return -EINVAL;
+
+	if (!cmd || !master)
+		return -EINVAL;
+
+	if (!master->ops->send_ccc_cmd)
+		return -ENOTSUPP;
+
+	if ((cmd->id & I3C_CCC_DIRECT)) {
+		enum i3c_addr_slot_status status;
+		int i;
+
+		if (!cmd->dests || !cmd->ndests)
+			return -EINVAL;
+
+		for (i = 0; i < cmd->ndests; i++) {
+			status = i3c_bus_get_addr_slot_status(master->bus,
+							cmd->dests[i].addr);
+			if (status != I3C_ADDR_SLOT_I3C_DEV)
+				return -EINVAL;
+		}
+	}
+
+	if (master->ops->supports_ccc_cmd &&
+	    !master->ops->supports_ccc_cmd(master, cmd))
+		return -ENOTSUPP;
+
+	return master->ops->send_ccc_cmd(master, cmd);
+}
+
+int i3c_master_send_hdr_cmds_locked(struct i3c_master_controller *master,
+				    const struct i3c_hdr_cmd *cmds, int ncmds)
+{
+	int i;
+
+	if (!cmds || !master || ncmds <= 0)
+		return -EINVAL;
+
+	if (!master->ops->send_hdr_cmds)
+		return -ENOTSUPP;
+
+	for (i = 0; i < ncmds; i++) {
+		if (!(master->this->info.hdr_cap & BIT(cmds->mode)))
+			return -ENOTSUPP;
+	}
+
+	return master->ops->send_hdr_cmds(master, cmds, ncmds);
+}
+
+/**
+ * i3c_master_send_hdr_cmds() - send HDR commands on the I3C bus
+ * @master: master used to send frames on the bus
+ * @cmds: array of HDR commands
+ * @ncmds: number of commands to send
+ *
+ * Send one or several HDR commands.
+ *
+ * This function can sleep and thus cannot be called in atomic context.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_send_hdr_cmds(struct i3c_master_controller *master,
+			     const struct i3c_hdr_cmd *cmds, int ncmds)
+{
+	int ret;
+
+	i3c_bus_normaluse_lock(master->bus);
+	ret = i3c_master_send_hdr_cmds_locked(master, cmds, ncmds);
+	i3c_bus_normaluse_unlock(master->bus);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_send_hdr_cmds);
+
+int i3c_master_do_priv_xfers_locked(struct i3c_master_controller *master,
+				    const struct i3c_priv_xfer *xfers,
+				    int nxfers)
+{
+	int i;
+
+	if (!xfers || !master || nxfers <= 0)
+		return -EINVAL;
+
+	if (!master->ops->priv_xfers)
+		return -ENOTSUPP;
+
+	for (i = 0; i < nxfers; i++) {
+		enum i3c_addr_slot_status status;
+
+		status = i3c_bus_get_addr_slot_status(master->bus,
+						      xfers[i].addr);
+		if (status != I3C_ADDR_SLOT_I3C_DEV)
+			return -EINVAL;
+	}
+
+	return master->ops->priv_xfers(master, xfers, nxfers);
+}
+
+/**
+ * i3c_master_do_priv_xfers() - do SDR private transfers on the I3C bus
+ * @master: master used to send frames on the bus
+ * @xfers: array of SDR private transfers
+ * @nxfers: number of transfers
+ *
+ * Do one or several private SDR I3C transfers.
+ *
+ * This function can sleep and thus cannot be called in atomic context.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_do_priv_xfers(struct i3c_master_controller *master,
+			     const struct i3c_priv_xfer *xfers,
+			     int nxfers)
+{
+	int ret;
+
+	i3c_bus_normaluse_lock(master->bus);
+	ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
+	i3c_bus_normaluse_unlock(master->bus);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_do_priv_xfers);
+
+/**
+ * i3c_master_do_i2c_xfers() - do I2C transfers on the I3C bus
+ * @master: master used to send frames on the bus
+ * @xfers: array of I2C transfers
+ * @nxfers: number of transfers
+ *
+ * Does one or several I2C transfers.
+ *
+ * This function can sleep and thus cannot be called in atomic context.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_do_i2c_xfers(struct i3c_master_controller *master,
+			    const struct i2c_msg *xfers,
+			    int nxfers)
+{
+	int ret, i;
+
+	if (!xfers || !master || nxfers <= 0)
+		return -EINVAL;
+
+	if (!master->ops->i2c_xfers)
+		return -ENOTSUPP;
+
+	i3c_bus_normaluse_lock(master->bus);
+
+	for (i = 0; i < nxfers; i++) {
+		enum i3c_addr_slot_status status;
+
+		status = i3c_bus_get_addr_slot_status(master->bus,
+						      xfers[i].addr);
+		if (status != I3C_ADDR_SLOT_I2C_DEV) {
+			ret = -EINVAL;
+			goto out;
+		}
+	}
+
+	ret = master->ops->i2c_xfers(master, xfers, nxfers);
+
+out:
+	i3c_bus_normaluse_unlock(master->bus);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_do_i2c_xfers);
+
+/**
+ * i3c_master_get_free_addr() - get a free address on the bus
+ * @master: I3C master object
+ * @start_addr: where to start searching
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: the first free address starting at @start_addr (included) or -ENOMEM
+ * if there's no more address available.
+ */
+int i3c_master_get_free_addr(struct i3c_master_controller *master,
+			     u8 start_addr)
+{
+	return i3c_bus_get_free_addr(master->bus, start_addr);
+}
+EXPORT_SYMBOL_GPL(i3c_master_get_free_addr);
+
+static void i3c_device_release(struct device *dev)
+{
+	struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+
+	of_node_put(dev->of_node);
+	kfree(i3cdev);
+}
+
+static struct i3c_device *
+i3c_master_alloc_i3c_dev(struct i3c_master_controller *master,
+			 const struct i3c_device_info *info,
+			 const struct device_type *devtype)
+{
+	struct i3c_device *dev;
+
+	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+	if (!dev)
+		return ERR_PTR(-ENOMEM);
+
+	i3c_i2c_dev_init(master, &dev->common, false);
+	dev->dev.parent = &master->bus->dev;
+	dev->dev.type = devtype;
+	dev->dev.bus = &i3c_bus_type;
+	dev->dev.release = i3c_device_release;
+	dev->info = *info;
+	dev->new = true;
+	mutex_init(&dev->ibi_lock);
+	dev_set_name(&dev->dev, "%d-%llx", master->bus->id, info->pid);
+
+	device_initialize(&dev->dev);
+
+	return dev;
+}
+
+/**
+ * i3c_master_set_info() - set master device information
+ * @master: master used to send frames on the bus
+ * @info: I3C device information
+ *
+ * Set master device info. This should be done in
+ * &i3c_master_controller_ops->bus_init().
+ *
+ * Not all &i3c_device_info fields are meaningful for a master device.
+ * Here is a list of fields that should be properly filled:
+ *
+ * - &i3c_device_info->dyn_addr
+ * - &i3c_device_info->bcr
+ * - &i3c_device_info->dcr
+ * - &i3c_device_info->pid
+ * - &i3c_device_info->hdr_cap if %I3C_BCR_HDR_CAP bit is set in
+ *   &i3c_device_info->bcr
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: 0 if @info contains valid information (not every piece of
+ * information can be checked, but we can at least make sure @info->dyn_addr
+ * and @info->bcr are correct), -EINVAL otherwise.
+ */
+int i3c_master_set_info(struct i3c_master_controller *master,
+			const struct i3c_device_info *info)
+{
+	struct i3c_device *i3cdev;
+
+	if (!i3c_bus_dev_addr_is_avail(master->bus, info->dyn_addr))
+		return -EINVAL;
+
+	if (I3C_BCR_DEVICE_ROLE(info->bcr) == I3C_BCR_I3C_MASTER &&
+	    master->secondary)
+		return -EINVAL;
+
+	if (master->this)
+		return -EINVAL;
+
+	i3cdev = i3c_master_alloc_i3c_dev(master, info,	&i3c_master_type);
+	if (IS_ERR(i3cdev))
+		return PTR_ERR(i3cdev);
+
+	master->this = i3cdev;
+	master->bus->cur_master = master->this;
+	list_add_tail(&i3cdev->common.node, &master->bus->devs.i3c);
+	i3c_bus_set_addr_slot_status(master->bus, info->dyn_addr,
+				     I3C_ADDR_SLOT_I3C_DEV);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(i3c_master_set_info);
+
+/**
+ * i3c_master_rstdaa_locked() - reset dev(s) dynamic address
+ * @master: master used to send frames on the bus
+ * @addr: a valid I3C device address or %I3C_BROADCAST_ADDR
+ *
+ * Send a RSTDAA CCC command to ask a specific slave (or all slave if @addr is
+ * %I3C_BROADCAST_ADDR) to drop their dynamic address.
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_rstdaa_locked(struct i3c_master_controller *master, u8 addr)
+{
+	struct i3c_ccc_cmd_dest dest = { };
+	struct i3c_ccc_cmd cmd = { };
+	enum i3c_addr_slot_status addrstat;
+	int ret;
+
+	if (!master)
+		return -EINVAL;
+
+	addrstat = i3c_bus_get_addr_slot_status(master->bus, addr);
+	if (addr != I3C_BROADCAST_ADDR && addrstat != I3C_ADDR_SLOT_I3C_DEV)
+		return -EINVAL;
+
+	dest.addr = addr;
+	cmd.dests = &dest;
+	cmd.ndests = 1;
+	cmd.rnw = false;
+	cmd.id = I3C_CCC_RSTDAA(addr == I3C_BROADCAST_ADDR);
+
+	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(i3c_master_rstdaa_locked);
+
+/**
+ * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
+ *				procedure
+ * @master: master used to send frames on the bus
+ *
+ * Send a ENTDAA CCC command to start a DAA procedure.
+ *
+ * Note that this function only sends the ENTDAA CCC command, all the logic
+ * behind dynamic address assignment has to be handled in the I3C master
+ * driver.
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_entdaa_locked(struct i3c_master_controller *master)
+{
+	struct i3c_ccc_cmd_dest dest = { };
+	struct i3c_ccc_cmd cmd = { };
+	int ret;
+
+	dest.addr = I3C_BROADCAST_ADDR;
+	cmd.dests = &dest;
+	cmd.ndests = 1;
+	cmd.rnw = false;
+	cmd.id = I3C_CCC_ENTDAA;
+
+	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked);
+
+/**
+ * i3c_master_disec_locked() - send a DISEC CCC command
+ * @master: master used to send frames on the bus
+ * @addr: a valid I3C slave address or %I3C_BROADCAST_ADDR
+ * @evts: events to disable
+ *
+ * Send a DISEC CCC command to disable some or all events coming from a
+ * specific slave, or all devices if @addr is %I3C_BROADCAST_ADDR.
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_disec_locked(struct i3c_master_controller *master, u8 addr,
+			    const struct i3c_ccc_events *evts)
+{
+	struct i3c_ccc_events events = *evts;
+	struct i3c_ccc_cmd_dest dest = {
+		.addr = addr,
+		.payload.len = sizeof(events),
+		.payload.data = &events,
+	};
+	struct i3c_ccc_cmd cmd = {
+		.id = I3C_CCC_DISEC(addr == I3C_BROADCAST_ADDR),
+		.dests = &dest,
+		.ndests = 1,
+	};
+
+	return i3c_master_send_ccc_cmd_locked(master, &cmd);
+}
+EXPORT_SYMBOL_GPL(i3c_master_disec_locked);
+
+/**
+ * i3c_master_enec_locked() - send an ENEC CCC command
+ * @master: master used to send frames on the bus
+ * @addr: a valid I3C slave address or %I3C_BROADCAST_ADDR
+ * @evts: events to disable
+ *
+ * Sends an ENEC CCC command to enable some or all events coming from a
+ * specific slave, or all devices if @addr is %I3C_BROADCAST_ADDR.
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_enec_locked(struct i3c_master_controller *master, u8 addr,
+			   const struct i3c_ccc_events *evts)
+{
+	struct i3c_ccc_events events = *evts;
+	struct i3c_ccc_cmd_dest dest = {
+		.addr = addr,
+		.payload.len = sizeof(events),
+		.payload.data = &events,
+	};
+	struct i3c_ccc_cmd cmd = {
+		.id = I3C_CCC_ENEC(addr == I3C_BROADCAST_ADDR),
+		.dests = &dest,
+		.ndests = 1,
+	};
+
+	return i3c_master_send_ccc_cmd_locked(master, &cmd);
+}
+EXPORT_SYMBOL_GPL(i3c_master_enec_locked);
+
+/**
+ * i3c_master_defslvs_locked() - send a DEFSLVS CCC command
+ * @master: master used to send frames on the bus
+ *
+ * Send a DEFSLVS CCC command containing all the devices known to the @master.
+ * This is useful when you have secondary masters on the bus to propagate
+ * device information.
+ *
+ * This should be called after all I3C devices have been discovered (in other
+ * words, after the DAA procedure has finished) and instantiated in
+ * i3c_master_controller_ops->bus_init().
+ * It should also be called if a master ACKed an Hot-Join request and assigned
+ * a dynamic address to the device joining the bus.
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_defslvs_locked(struct i3c_master_controller *master)
+{
+	struct i3c_ccc_cmd_dest dest = {
+		.addr = I3C_BROADCAST_ADDR,
+	};
+	struct i3c_ccc_cmd cmd = {
+		.id = I3C_CCC_DEFSLVS,
+		.dests = &dest,
+		.ndests = 1,
+	};
+	struct i3c_ccc_defslvs *defslvs;
+	struct i3c_ccc_dev_desc *desc;
+	struct i3c_device *i3cdev;
+	struct i2c_device *i2cdev;
+	struct i3c_bus *bus;
+	bool send = false;
+	int ndevs = 0, ret;
+
+	if (!master)
+		return -EINVAL;
+
+	bus = i3c_master_get_bus(master);
+	i3c_bus_for_each_i3cdev(bus, i3cdev) {
+		ndevs++;
+		if (I3C_BCR_DEVICE_ROLE(i3cdev->info.bcr) == I3C_BCR_I3C_MASTER)
+			send = true;
+	}
+
+	/* No other master on the bus, skip DEFSLVS. */
+	if (!send)
+		return 0;
+
+	i3c_bus_for_each_i2cdev(bus, i2cdev)
+		ndevs++;
+
+	dest.payload.len = sizeof(*defslvs) +
+			   ((ndevs - 1) * sizeof(struct i3c_ccc_dev_desc));
+	defslvs = kzalloc(dest.payload.len, GFP_KERNEL);
+	if (!defslvs)
+		return -ENOMEM;
+
+	dest.payload.data = defslvs;
+
+	defslvs->count = ndevs;
+	defslvs->master.bcr = master->this->info.bcr;
+	defslvs->master.dcr = master->this->info.dcr;
+	defslvs->master.dyn_addr = master->this->info.dyn_addr;
+	defslvs->master.static_addr = I3C_BROADCAST_ADDR;
+
+	desc = defslvs->slaves;
+	i3c_bus_for_each_i2cdev(bus, i2cdev) {
+		desc->lvr = i2cdev->lvr;
+		desc->static_addr = i2cdev->info.addr;
+		desc++;
+	}
+
+	i3c_bus_for_each_i3cdev(bus, i3cdev) {
+		/* Skip the I3C dev representing this master. */
+		if (i3cdev == master->this)
+			continue;
+
+		desc->bcr = i3cdev->info.bcr;
+		desc->dcr = i3cdev->info.dcr;
+		desc->dyn_addr = i3cdev->info.dyn_addr;
+		desc->static_addr = i3cdev->info.static_addr;
+		desc++;
+	}
+
+	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+	kfree(defslvs);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_defslvs_locked);
+
+static int i3c_master_getmrl_locked(struct i3c_master_controller *master,
+				    struct i3c_device_info *info)
+{
+	struct i3c_ccc_mrl mrl;
+	struct i3c_ccc_cmd_dest dest = {
+		.addr = info->dyn_addr,
+		.payload.len = sizeof(mrl),
+		.payload.data = &mrl,
+	};
+	struct i3c_ccc_cmd cmd = {
+		.rnw = true,
+		.id = I3C_CCC_GETMRL,
+		.dests = &dest,
+		.ndests = 1,
+	};
+	int ret;
+
+	/*
+	 * When the device does not have IBI payload GETMRL only returns 2
+	 * bytes of data.
+	 */
+	if (!(info->bcr & I3C_BCR_IBI_PAYLOAD))
+		dest.payload.len -= 1;
+
+	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+	if (ret)
+		return ret;
+
+	if (dest.payload.len != sizeof(mrl))
+		return -EIO;
+
+	info->max_read_len = be16_to_cpu(mrl.read_len);
+
+	if (info->bcr & I3C_BCR_IBI_PAYLOAD)
+		info->max_ibi_len = mrl.ibi_len;
+
+	return 0;
+}
+
+static int i3c_master_getmwl_locked(struct i3c_master_controller *master,
+				    struct i3c_device_info *info)
+{
+	struct i3c_ccc_mwl mwl;
+	struct i3c_ccc_cmd_dest dest = {
+		.addr = info->dyn_addr,
+		.payload.len = sizeof(mwl),
+		.payload.data = &mwl,
+	};
+	struct i3c_ccc_cmd cmd = {
+		.rnw = true,
+		.id = I3C_CCC_GETMWL,
+		.dests = &dest,
+		.ndests = 1,
+	};
+	int ret;
+
+	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+	if (ret)
+		return ret;
+
+	if (dest.payload.len != sizeof(mwl))
+		return -EIO;
+
+	info->max_write_len = be16_to_cpu(mwl.len);
+
+	return 0;
+}
+
+static int i3c_master_getmxds_locked(struct i3c_master_controller *master,
+				     struct i3c_device_info *info)
+{
+	struct i3c_ccc_getmxds getmaxds;
+	struct i3c_ccc_cmd_dest dest = {
+		.addr = info->dyn_addr,
+		.payload.len = sizeof(getmaxds),
+		.payload.data = &getmaxds,
+	};
+	struct i3c_ccc_cmd cmd = {
+		.rnw = true,
+		.id = I3C_CCC_GETMXDS,
+		.dests = &dest,
+		.ndests = 1,
+	};
+	int ret;
+
+	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+	if (ret)
+		return ret;
+
+	if (dest.payload.len != 2 && dest.payload.len != 5)
+		return -EIO;
+
+	info->max_read_ds = getmaxds.maxrd;
+	info->max_read_ds = getmaxds.maxwr;
+	if (dest.payload.len == 5)
+		info->max_read_turnaround = getmaxds.maxrdturn[0] |
+					    ((u32)getmaxds.maxrdturn[1] << 8) |
+					    ((u32)getmaxds.maxrdturn[2] << 16);
+
+	return 0;
+}
+
+static int i3c_master_gethdrcap_locked(struct i3c_master_controller *master,
+				       struct i3c_device_info *info)
+{
+	struct i3c_ccc_gethdrcap gethdrcap;
+	struct i3c_ccc_cmd_dest dest = {
+		.addr = info->dyn_addr,
+		.payload.len = sizeof(gethdrcap),
+		.payload.data = &gethdrcap,
+	};
+	struct i3c_ccc_cmd cmd = {
+		.rnw = true,
+		.id = I3C_CCC_GETHDRCAP,
+		.dests = &dest,
+		.ndests = 1,
+	};
+	int ret;
+
+	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+	if (ret)
+		return ret;
+
+	if (dest.payload.len != 1)
+		return -EIO;
+
+	info->hdr_cap = gethdrcap.modes;
+
+	return 0;
+}
+
+static int i3c_master_getpid_locked(struct i3c_master_controller *master,
+				    struct i3c_device_info *info)
+{
+	struct i3c_ccc_getpid getpid;
+	struct i3c_ccc_cmd_dest dest = {
+		.addr = info->dyn_addr,
+		.payload.len = sizeof(struct i3c_ccc_getpid),
+		.payload.data = &getpid,
+	};
+	struct i3c_ccc_cmd cmd = {
+		.rnw = true,
+		.id = I3C_CCC_GETPID,
+		.dests = &dest,
+		.ndests = 1,
+	};
+	int ret, i;
+
+	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+	if (ret)
+		return ret;
+
+	info->pid = 0;
+	for (i = 0; i < sizeof(getpid.pid); i++) {
+		int sft = (sizeof(getpid.pid) - i - 1) * 8;
+
+		info->pid |= (u64)getpid.pid[i] << sft;
+	}
+
+	return 0;
+}
+
+static int i3c_master_getbcr_locked(struct i3c_master_controller *master,
+				    struct i3c_device_info *info)
+{
+	struct i3c_ccc_getbcr getbcr;
+	struct i3c_ccc_cmd_dest dest = {
+		.addr = info->dyn_addr,
+		.payload.len = sizeof(struct i3c_ccc_getbcr),
+		.payload.data = &getbcr,
+	};
+	struct i3c_ccc_cmd cmd = {
+		.rnw = true,
+		.id = I3C_CCC_GETBCR,
+		.dests = &dest,
+		.ndests = 1,
+	};
+	int ret;
+
+	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+	if (ret)
+		return ret;
+
+	info->bcr = getbcr.bcr;
+
+	return 0;
+}
+
+static int i3c_master_getdcr_locked(struct i3c_master_controller *master,
+				    struct i3c_device_info *info)
+{
+	struct i3c_ccc_getdcr getdcr;
+	struct i3c_ccc_cmd_dest dest = {
+		.addr = info->dyn_addr,
+		.payload.len = sizeof(struct i3c_ccc_getdcr),
+		.payload.data = &getdcr,
+	};
+	struct i3c_ccc_cmd cmd = {
+		.rnw = true,
+		.id = I3C_CCC_GETDCR,
+		.dests = &dest,
+		.ndests = 1,
+	};
+	int ret;
+
+	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+	if (ret)
+		return ret;
+
+	info->dcr = getdcr.dcr;
+
+	return 0;
+}
+
+static int i3c_master_retrieve_dev_info(struct i3c_master_controller *master,
+					struct i3c_device_info *info, u8 addr)
+{
+	enum i3c_addr_slot_status slot_status;
+	int ret;
+
+	if (!master || !info)
+		return -EINVAL;
+
+	memset(info, 0, sizeof(*info));
+	info->dyn_addr = addr;
+
+	slot_status = i3c_bus_get_addr_slot_status(master->bus,
+						   info->dyn_addr);
+	if (slot_status == I3C_ADDR_SLOT_RSVD ||
+	    slot_status == I3C_ADDR_SLOT_I2C_DEV)
+		return -EINVAL;
+
+	ret = i3c_master_getpid_locked(master, info);
+	if (ret)
+		return ret;
+
+	ret = i3c_master_getbcr_locked(master, info);
+	if (ret)
+		return ret;
+
+	ret = i3c_master_getdcr_locked(master, info);
+	if (ret)
+		return ret;
+
+	if (info->bcr & I3C_BCR_MAX_DATA_SPEED_LIM) {
+		ret = i3c_master_getmxds_locked(master, info);
+		if (ret)
+			return ret;
+	}
+
+	if (info->bcr & I3C_BCR_IBI_PAYLOAD)
+		info->max_ibi_len = 1;
+
+	i3c_master_getmrl_locked(master, info);
+	i3c_master_getmwl_locked(master, info);
+
+	if (info->bcr & I3C_BCR_HDR_CAP) {
+		ret = i3c_master_gethdrcap_locked(master, info);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+/**
+ * i3c_master_add_i3c_dev_locked() - add an I3C slave to the bus
+ * @master: master used to send frames on the bus
+ * @addr: I3C slave dynamic address assigned to the device
+ *
+ * This function is instantiating an I3C device object and adding it to the
+ * I3C device list. All device information are automatically retrieved using
+ * standard CCC commands.
+ *
+ * The I3C device object is returned in case the master wants to attach
+ * private data to it using i3c_device_set_master_data().
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: a pointer to a &struct i3c_device object in case of success,
+ * an ERR_PTR() otherwise.
+ */
+struct i3c_device *
+i3c_master_add_i3c_dev_locked(struct i3c_master_controller *master, u8 addr)
+{
+	enum i3c_addr_slot_status status;
+	struct i3c_device *i3cdev;
+	struct i3c_device_info info;
+	int ret;
+
+	if (!master)
+		return ERR_PTR(-EINVAL);
+
+	status = i3c_bus_get_addr_slot_status(master->bus, addr);
+	if (status != I3C_ADDR_SLOT_FREE)
+		return ERR_PTR(-EINVAL);
+
+	i3c_bus_set_addr_slot_status(master->bus, addr, I3C_ADDR_SLOT_I3C_DEV);
+
+	ret = i3c_master_retrieve_dev_info(master, &info, addr);
+	if (ret)
+		goto err_release_addr;
+
+	i3cdev = i3c_master_alloc_i3c_dev(master, &info, &i3c_device_type);
+	if (IS_ERR(i3cdev)) {
+		ret = PTR_ERR(i3cdev);
+		goto err_release_addr;
+	}
+
+	list_add_tail(&i3cdev->common.node, &master->bus->devs.i3c);
+
+	return i3cdev;
+
+err_release_addr:
+	i3c_bus_set_addr_slot_status(master->bus, addr, I3C_ADDR_SLOT_FREE);
+
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(i3c_master_add_i3c_dev_locked);
+
+static int of_i3c_master_add_dev(struct i3c_master_controller *master,
+				 struct device_node *node)
+{
+	struct device *dev = master->parent;
+	struct i2c_board_info info = { };
+	struct i2c_device *i2cdev;
+	u32 lvr, addr;
+	int ret;
+
+	if (!master || !node)
+		return -EINVAL;
+
+	/*
+	 * This node is not describing an I2C device, skip it.
+	 * We only add I2C devices here (i.e. nodes with an i3c-lvr property).
+	 * I3C devices will be discovered during DAA, even if they have a
+	 * static address.
+	 */
+	if (of_property_read_u32(node, "reg", &addr) ||
+	    of_property_read_u32(node, "i3c-lvr", &lvr))
+		return 0;
+
+	ret = of_i2c_get_board_info(master->parent, node, &info);
+	if (ret)
+		return ret;
+
+	/*
+	 * We do not register the I2C device here, because the bus is not
+	 * necessarily ready to transmit I2C frames, and the I2C adapter has
+	 * not been registered yet.
+	 * This is done in i3c_master_i2c_adapter_init() once everything is
+	 * ready.
+	 */
+	i2cdev = i3c_master_alloc_i2c_dev(master, &info, lvr);
+	if (IS_ERR(i2cdev)) {
+		dev_err(dev, "Failed to allocate device %02x\n", addr);
+		return ret;
+	}
+
+	if (lvr & I3C_LVR_I2C_FM_MODE)
+		master->bus->scl_rate.i2c = I3C_BUS_I2C_FM_SCL_RATE;
+
+	list_add_tail(&i2cdev->common.node, &master->bus->devs.i2c);
+
+	return 0;
+}
+
+static int of_populate_i3c_bus(struct i3c_master_controller *master)
+{
+	struct device *dev = &master->bus->dev;
+	struct device_node *i3cbus_np = dev->of_node;
+	struct device_node *node;
+	int ret;
+	u32 val;
+
+	if (!i3cbus_np)
+		return 0;
+
+	for_each_available_child_of_node(i3cbus_np, node) {
+		ret = of_i3c_master_add_dev(master, node);
+		if (ret)
+			return ret;
+	}
+
+	/*
+	 * The user might want to limit I2C and I3C speed in case some devices
+	 * on the bus are not supporting typical rates, or if the bus topology
+	 * prevents it from using max possible rate.
+	 */
+	if (!of_property_read_u32(i3cbus_np, "i2c-scl-frequency", &val))
+		master->bus->scl_rate.i2c = val;
+
+	if (!of_property_read_u32(i3cbus_np, "i3c-scl-frequency", &val))
+		master->bus->scl_rate.i3c = val;
+
+	return 0;
+}
+
+static int i3c_master_i2c_adapter_xfer(struct i2c_adapter *adap,
+				       struct i2c_msg *xfers, int nxfers)
+{
+	struct i3c_master_controller *master = i2c_adapter_to_i3c_master(adap);
+	int i, ret;
+
+	for (i = 0; i < nxfers; i++) {
+		enum i3c_addr_slot_status status;
+
+		status = i3c_bus_get_addr_slot_status(master->bus,
+						      xfers[i].addr);
+		if (status != I3C_ADDR_SLOT_I2C_DEV)
+			return -EINVAL;
+	}
+
+	ret = i3c_master_do_i2c_xfers(master, xfers, nxfers);
+	if (ret)
+		return ret;
+
+	return nxfers;
+}
+
+static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap)
+{
+	return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR;
+}
+
+static const struct i2c_algorithm i3c_master_i2c_algo = {
+	.master_xfer = i3c_master_i2c_adapter_xfer,
+	.functionality = i3c_master_i2c_functionalities,
+};
+
+static int i3c_master_i2c_adapter_init(struct i3c_master_controller *master)
+{
+	struct i2c_adapter *adap = i3c_master_to_i2c_adapter(master);
+	struct i2c_device *i2cdev;
+	int ret;
+
+	adap->dev.parent = master->parent;
+	adap->owner = master->parent->driver->owner;
+	adap->algo = &i3c_master_i2c_algo;
+	strncpy(adap->name, dev_name(master->parent), sizeof(adap->name));
+
+	/* FIXME: Should we allow i3c masters to override these values? */
+	adap->timeout = 1000;
+	adap->retries = 3;
+
+	ret = i2c_add_adapter(adap);
+	if (ret)
+		return ret;
+
+	/*
+	 * We silently ignore failures here. The bus should keep working
+	 * correctly even if one or more i2c devices are not registered.
+	 */
+	i3c_bus_for_each_i2cdev(master->bus, i2cdev)
+		i2cdev->client = i2c_new_device(adap, &i2cdev->info);
+
+	return 0;
+}
+
+static void i3c_master_i2c_adapter_cleanup(struct i3c_master_controller *master)
+{
+	i2c_del_adapter(&master->i2c);
+}
+
+static void i3c_master_unregister_i3c_devs(struct i3c_master_controller *master)
+{
+	struct i3c_device *i3cdev;
+
+	i3c_bus_for_each_i3cdev(master->bus, i3cdev) {
+		if (device_is_registered(&i3cdev->dev))
+			device_del(&i3cdev->dev);
+	}
+}
+
+/**
+ * i3c_device_queue_ibi() - Queue an IBI
+ * @dev: the device this IBI is coming from
+ * @slot: the IBI slot used to store the payload
+ *
+ * Queue an IBI to the controller workqueue. The IBI handler attached to
+ * the dev will be called from a workqueue context.
+ */
+void i3c_device_queue_ibi(struct i3c_device *dev, struct i3c_ibi_slot *slot)
+{
+	atomic_inc(&dev->ibi->pending_ibis);
+	queue_work(dev->common.master->wq, &slot->work);
+}
+EXPORT_SYMBOL_GPL(i3c_device_queue_ibi);
+
+static void i3c_device_handle_ibi(struct work_struct *work)
+{
+	struct i3c_ibi_slot *slot = container_of(work, struct i3c_ibi_slot,
+						 work);
+	struct i3c_device *dev = slot->dev;
+	struct i3c_master_controller *master = i3c_device_get_master(dev);
+	struct i3c_ibi_payload payload;
+
+	payload.data = slot->data;
+	payload.len = slot->len;
+
+	dev->ibi->handler(dev, &payload);
+	master->ops->recycle_ibi_slot(master, dev, slot);
+	if (atomic_dec_and_test(&dev->ibi->pending_ibis))
+		complete(&dev->ibi->all_ibis_handled);
+}
+
+/**
+ * i3c_device_init_ibi_slot() - Initialize an IBI slot
+ * @dev: the device this IBI slot will be attached to
+ * @slot: the IBI slot to initialze
+ *
+ * Initialize an IBI slot so that it can later be queued using
+ * i3c_device_queue_ibi(). This should be done at allocation time when the IBI
+ * slot pool is created.
+ */
+void i3c_device_init_ibi_slot(struct i3c_device *dev,
+			      struct i3c_ibi_slot *slot)
+{
+	slot->dev = dev;
+	INIT_WORK(&slot->work, i3c_device_handle_ibi);
+}
+EXPORT_SYMBOL_GPL(i3c_device_init_ibi_slot);
+
+struct i3c_generic_ibi_slot {
+	struct list_head node;
+	struct i3c_ibi_slot base;
+};
+
+struct i3c_generic_ibi_pool {
+	spinlock_t lock;
+	unsigned int num_slots;
+	struct list_head free_slots;
+	struct list_head pending;
+};
+
+/**
+ * i3c_generic_ibi_free_pool() - Free a generic IBI pool
+ * @pool: the IBI pool to free
+ *
+ * Free all IBI slots allated by a generic IBI pool.
+ */
+void i3c_generic_ibi_free_pool(struct i3c_generic_ibi_pool *pool)
+{
+	struct i3c_generic_ibi_slot *slot;
+	unsigned int nslots = 0;
+
+	while (!list_empty(&pool->free_slots)) {
+		slot = list_first_entry(&pool->free_slots,
+					struct i3c_generic_ibi_slot, node);
+		list_del(&slot->node);
+		kfree(slot->base.data);
+		kfree(slot);
+		nslots++;
+	}
+
+	/*
+	 * If the number of freed slots is not equal to the number of allocated
+	 * slots we have a leak somewhere.
+	 */
+	WARN_ON(nslots != pool->num_slots);
+}
+EXPORT_SYMBOL_GPL(i3c_generic_ibi_free_pool);
+
+/**
+ * i3c_generic_ibi_alloc_pool() - Create a generic IBI pool
+ * @dev: the device this pool will be used for
+ * @req: IBI setup request describing what the device driver expects
+ *
+ * Create a generic IBI pool based on the information provided in @req.
+ *
+ * Return: a valid IBI pool in case of success, an ERR_PTR() otherwise.
+ */
+struct i3c_generic_ibi_pool *
+i3c_generic_ibi_alloc_pool(struct i3c_device *dev,
+			   const struct i3c_ibi_setup *req)
+{
+	struct i3c_generic_ibi_pool *pool;
+	struct i3c_generic_ibi_slot *slot;
+	unsigned int i;
+	int ret;
+
+	pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+	if (!pool)
+		return ERR_PTR(-ENOMEM);
+
+	spin_lock_init(&pool->lock);
+	INIT_LIST_HEAD(&pool->free_slots);
+	INIT_LIST_HEAD(&pool->pending);
+
+	for (i = 0; i < req->num_slots; i++) {
+		slot = kzalloc(sizeof(*slot), GFP_KERNEL);
+		if (!slot)
+			return ERR_PTR(-ENOMEM);
+
+		i3c_device_init_ibi_slot(dev, &slot->base);
+
+		if (req->max_payload_len) {
+			slot->base.data = kzalloc(req->max_payload_len,
+						  GFP_KERNEL);
+			if (!slot->base.data) {
+				kfree(slot);
+				ret = -ENOMEM;
+				goto err_free_pool;
+			}
+		}
+
+		list_add_tail(&slot->node, &pool->free_slots);
+		pool->num_slots++;
+	}
+
+	return pool;
+
+err_free_pool:
+	i3c_generic_ibi_free_pool(pool);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(i3c_generic_ibi_alloc_pool);
+
+/**
+ * i3c_generic_ibi_get_free_slot() - Get a free slot from a generic IBI pool
+ * @pool: the pool to query an IBI slot on
+ *
+ * Search for a free slot in a generic IBI pool.
+ * The slot should be returned to the pool using i3c_generic_ibi_recycle_slot()
+ * when it's no longer needed.
+ *
+ * Return: a pointer to a free slot, or NULL if there's no free slot available.
+ */
+struct i3c_ibi_slot *
+i3c_generic_ibi_get_free_slot(struct i3c_generic_ibi_pool *pool)
+{
+	struct i3c_generic_ibi_slot *slot;
+	unsigned long flags;
+
+	spin_lock_irqsave(&pool->lock, flags);
+	slot = list_first_entry_or_null(&pool->free_slots,
+					struct i3c_generic_ibi_slot, node);
+	if (slot)
+		list_del(&slot->node);
+	spin_unlock_irqrestore(&pool->lock, flags);
+
+	return slot ? &slot->base : NULL;
+}
+EXPORT_SYMBOL_GPL(i3c_generic_ibi_get_free_slot);
+
+/**
+ * i3c_generic_ibi_recycle_slot() - Return a slot to a generic IBI pool
+ * @pool: the pool to return the IBI slot to
+ *
+ * Add an IBI slot back to its generic IBI pool. Should be called from the
+ * master driver struct_master_controller_ops->recycle_ibi() method.
+ */
+void i3c_generic_ibi_recycle_slot(struct i3c_generic_ibi_pool *pool,
+				  struct i3c_ibi_slot *s)
+{
+	struct i3c_generic_ibi_slot *slot;
+	unsigned long flags;
+
+	if (!s)
+		return;
+
+	slot = container_of(s, struct i3c_generic_ibi_slot, base);
+	spin_lock_irqsave(&pool->lock, flags);
+	list_add_tail(&slot->node, &pool->free_slots);
+	spin_unlock_irqrestore(&pool->lock, flags);
+}
+EXPORT_SYMBOL_GPL(i3c_generic_ibi_recycle_slot);
+
+/**
+ * i3c_master_register_new_i3c_devs() - register I3C devs that have been
+ *					plugged after the bus initialization
+ * @master: the master device these I3C devs have been attached to
+ *
+ * This is meant to be used when devices are discovered after the bus
+ * initialization, either because they sent a Hot-Join request which has
+ * been accepted by the master, or because the master has been asked to
+ * do a new DAA.
+ */
+void i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
+{
+	struct i3c_device *i3cdev;
+	int ret;
+
+	i3c_bus_for_each_i3cdev(master->bus, i3cdev) {
+		if (!i3cdev->new)
+			continue;
+
+		ret = device_add(&i3cdev->dev);
+		if (ret)
+			dev_err(master->parent,
+				"Failed to add I3C device (err = %d)\n", ret);
+
+		i3cdev->new = false;
+	}
+}
+EXPORT_SYMBOL_GPL(i3c_master_register_new_i3c_devs);
+
+static int i3c_master_init_bus(struct i3c_master_controller *master)
+{
+	int ret;
+
+	if (!master->ops->bus_init)
+		return 0;
+
+	/*
+	 * Take an exclusive lock on the bus before calling ->bus_init(), so
+	 * that all _locked() helpers can safely be called within this hook.
+	 */
+	i3c_bus_maintenance_lock(master->bus);
+	ret = master->ops->bus_init(master);
+	i3c_bus_maintenance_unlock(master->bus);
+
+	return ret;
+}
+
+static void i3c_master_cleanup_bus(struct i3c_master_controller *master)
+{
+	if (master->ops->bus_cleanup) {
+		/*
+		 * Take an exclusive lock on the bus before calling
+		 * ->bus_cleanup(), so that all _locked() helpers can safely be
+		 * called within this hook.
+		 */
+		i3c_bus_maintenance_lock(master->bus);
+		master->ops->bus_cleanup(master);
+		i3c_bus_maintenance_unlock(master->bus);
+	}
+}
+
+static void i3c_master_destroy_bus(struct i3c_master_controller *master)
+{
+	i3c_bus_unregister(master->bus);
+}
+
+static int i3c_master_create_bus(struct i3c_master_controller *master)
+{
+	struct i3c_bus *i3cbus;
+	int ret;
+
+	i3cbus = i3c_bus_create(master->parent);
+	if (IS_ERR(i3cbus))
+		return PTR_ERR(i3cbus);
+
+	master->bus = i3cbus;
+
+	if (i3cbus->dev.of_node) {
+		ret = of_populate_i3c_bus(master);
+		if (ret)
+			goto err_destroy_bus;
+	}
+
+	ret = i3c_bus_register(i3cbus);
+	if (ret)
+		goto err_destroy_bus;
+
+	return 0;
+
+err_destroy_bus:
+	i3c_bus_unref(i3cbus);
+
+	return ret;
+}
+
+/**
+ * i3c_master_register() - register an I3C master
+ * @master: master used to send frames on the bus
+ * @parent: the parent device (the one that provides this I3C master
+ *	    controller)
+ * @ops: the master controller operations
+ * @secondary: true if you are registering a secondary master. Will return
+ *	       -ENOTSUPP if set to true since secondary masters are not yet
+ *	       supported
+ *
+ * This function takes care of everything for you:
+ *
+ * - creates and initializes the I3C bus
+ * - populates the bus with static I2C devs if @parent->of_node is not
+ *   NULL
+ * - registers all I3C devices added by the controller during bus
+ *   initialization
+ * - registers the I2C adapter and all I2C devices
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_register(struct i3c_master_controller *master,
+			struct device *parent,
+			const struct i3c_master_controller_ops *ops,
+			bool secondary)
+{
+	int ret;
+
+	/* We do not support secondary masters yet. */
+	if (secondary)
+		return -ENOTSUPP;
+
+	master->parent = parent;
+	master->ops = ops;
+	master->secondary = secondary;
+
+	ret = i3c_master_create_bus(master);
+	if (ret)
+		return ret;
+
+	/*
+	 * Before doing any operation on the bus, we need to initialize it.
+	 * This operation is highly controller dependent, but it is expected
+	 * to do the following operations:
+	 * 1/ reset all addresses of all devices on the bus (using RSTDAA CCC
+	 *    command)
+	 * 2/ start a DAA (Dynamic Address Assignment) procedure
+	 * 3/ populate the bus with all I3C devices discovered during DAA using
+	 *
+	 */
+	ret = i3c_master_init_bus(master);
+	if (ret)
+		goto err_destroy_bus;
+
+	master->wq = alloc_workqueue("%s", 0, 0, dev_name(parent));
+	if (!master->wq) {
+		ret = -ENOMEM;
+		goto err_cleanup_bus;
+	}
+
+	/* Register all I3C devs that have been added during DAA. */
+	i3c_master_register_new_i3c_devs(master);
+
+	/*
+	 * This is the last step: expose our i3c bus as an i2c adapter so that
+	 * i2c devices are exposed through the i2c subsystem.
+	 */
+	ret = i3c_master_i2c_adapter_init(master);
+	if (ret)
+		goto err_unreg_i3c_devs;
+
+	return 0;
+
+err_unreg_i3c_devs:
+	i3c_master_unregister_i3c_devs(master);
+	destroy_workqueue(master->wq);
+
+err_cleanup_bus:
+	i3c_master_cleanup_bus(master);
+
+err_destroy_bus:
+	i3c_master_destroy_bus(master);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_register);
+
+/**
+ * i3c_master_unregister() - unregister an I3C master
+ * @master: master used to send frames on the bus
+ *
+ * Basically undo everything done in i3c_master_register().
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_unregister(struct i3c_master_controller *master)
+{
+	i3c_master_i2c_adapter_cleanup(master);
+
+	i3c_master_unregister_i3c_devs(master);
+
+	destroy_workqueue(master->wq);
+
+	i3c_master_cleanup_bus(master);
+
+	i3c_master_destroy_bus(master);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(i3c_master_unregister);
diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
new file mode 100644
index 000000000000..e69de29bb2d1
diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
new file mode 100644
index 000000000000..e69de29bb2d1
diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h
new file mode 100644
index 000000000000..ff3e1a3e2c4c
--- /dev/null
+++ b/include/linux/i3c/ccc.h
@@ -0,0 +1,380 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ */
+
+#ifndef I3C_CCC_H
+#define I3C_CCC_H
+
+/* I3C CCC (Common Command Codes) related definitions */
+#define I3C_CCC_DIRECT			BIT(7)
+
+#define I3C_CCC_ID(id, broadcast)	\
+	((id) | ((broadcast) ? 0 : I3C_CCC_DIRECT))
+
+/* Commands valid in both broadcast and unicast modes */
+#define I3C_CCC_ENEC(broadcast)		I3C_CCC_ID(0x0, broadcast)
+#define I3C_CCC_DISEC(broadcast)	I3C_CCC_ID(0x1, broadcast)
+#define I3C_CCC_ENTAS(as, broadcast)	I3C_CCC_ID(0x2 + (as), broadcast)
+#define I3C_CCC_RSTDAA(broadcast)	I3C_CCC_ID(0x6, broadcast)
+#define I3C_CCC_SETMWL(broadcast)	I3C_CCC_ID(0x9, broadcast)
+#define I3C_CCC_SETMRL(broadcast)	I3C_CCC_ID(0xa, broadcast)
+#define I3C_CCC_SETXTIME(broadcast)	((broadcast) ? 0x28 : 0x98)
+#define I3C_CCC_VENDOR(id, broadcast)	((id) + ((broadcast) ? 0x61 : 0xe0))
+
+/* Broadcast-only commands */
+#define I3C_CCC_ENTDAA			I3C_CCC_ID(0x7, true)
+#define I3C_CCC_DEFSLVS			I3C_CCC_ID(0x8, true)
+#define I3C_CCC_ENTTM			I3C_CCC_ID(0xb, true)
+#define I3C_CCC_ENTHDR(x)		I3C_CCC_ID(0x20 + (x), true)
+
+/* Unicast-only commands */
+#define I3C_CCC_SETDASA			I3C_CCC_ID(0x7, false)
+#define I3C_CCC_SETNEWDA		I3C_CCC_ID(0x8, false)
+#define I3C_CCC_GETMWL			I3C_CCC_ID(0xb, false)
+#define I3C_CCC_GETMRL			I3C_CCC_ID(0xc, false)
+#define I3C_CCC_GETPID			I3C_CCC_ID(0xd, false)
+#define I3C_CCC_GETBCR			I3C_CCC_ID(0xe, false)
+#define I3C_CCC_GETDCR			I3C_CCC_ID(0xf, false)
+#define I3C_CCC_GETSTATUS		I3C_CCC_ID(0x10, false)
+#define I3C_CCC_GETACCMST		I3C_CCC_ID(0x11, false)
+#define I3C_CCC_SETBRGTGT		I3C_CCC_ID(0x13, false)
+#define I3C_CCC_GETMXDS			I3C_CCC_ID(0x14, false)
+#define I3C_CCC_GETHDRCAP		I3C_CCC_ID(0x15, false)
+#define I3C_CCC_GETXTIME		I3C_CCC_ID(0x19, false)
+
+#define I3C_CCC_EVENT_SIR		BIT(0)
+#define I3C_CCC_EVENT_MR		BIT(1)
+#define I3C_CCC_EVENT_HJ		BIT(3)
+
+/**
+ * struct i3c_ccc_events - payload passed to ENEC/DISEC CCC
+ *
+ * @events: bitmask of I3C_CCC_EVENT_xxx events.
+ *
+ * Depending on the CCC command, the specific events coming from all devices
+ * (broadcast version) or a specific device (unicast version) will be
+ * enabled (ENEC) or disabled (DISEC).
+ */
+struct i3c_ccc_events {
+	u8 events;
+} __packed;
+
+/**
+ * struct i3c_ccc_mwl - payload passed to SETMWL/GETMWL CCC
+ *
+ * @len: maximum write length in bytes
+ *
+ * The maximum write length is only applicable to SDR private messages or
+ * extended Write CCCs (like SETXTIME).
+ */
+struct i3c_ccc_mwl {
+	__be16 len;
+} __packed;
+
+/**
+ * struct i3c_ccc_mrl - payload passed to SETMRL/GETMRL CCC
+ *
+ * @len: maximum read length in bytes
+ * @ibi_len: maximum IBI payload length
+ *
+ * The maximum read length is only applicable to SDR private messages or
+ * extended Read CCCs (like GETXTIME).
+ * The IBI length is only valid if the I3C slave is IBI capable
+ * (%I3C_BCR_IBI_REQ_CAP is set).
+ */
+struct i3c_ccc_mrl {
+	__be16 read_len;
+	u8 ibi_len;
+} __packed;
+
+/**
+ * struct i3c_ccc_dev_desc - I3C/I3C device descriptor used for DEFSLVS
+ *
+ * @dyn_addr: dynamic address assigned to the I3C slave or 0 if the entry is
+ *	      describing an I2C slave.
+ * @dcr: DCR value (not applicable to entries describing I2C devices)
+ * @lvr: LVR value (not applicable to entries describing I3C devices)
+ * @bcr: BCR value or 0 if this entry is describing an I2C slave
+ * @static_addr: static address or 0 if the device does not have a static
+ *		 address
+ *
+ * The DEFSLVS command should be passed an array of i3c_ccc_dev_desc
+ * descriptors (one entry per I3C/I2C dev controlled by the master).
+ */
+struct i3c_ccc_dev_desc {
+	u8 dyn_addr;
+	union {
+		u8 dcr;
+		u8 lvr;
+	};
+	u8 bcr;
+	u8 static_addr;
+} __packed;
+
+/**
+ * struct i3c_ccc_defslvs - payload passed to DEFSLVS CCC
+ *
+ * @count: number of dev descriptors
+ * @master: descriptor describing the current master
+ * @slaves: array of descriptors describing slaves controlled by the
+ *	    current master
+ *
+ * Information passed to the broadcast DEFSLVS to propagate device
+ * information to all masters currently acting as slaves on the bus.
+ * This is only meaningful if you have more than one master.
+ */
+struct i3c_ccc_defslvs {
+	u8 count;
+	struct i3c_ccc_dev_desc master;
+	struct i3c_ccc_dev_desc slaves[0];
+} __packed;
+
+/**
+ * enum i3c_ccc_test_mode - enum listing all available test modes
+ *
+ * @I3C_CCC_EXIT_TEST_MODE: exit test mode
+ * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode
+ */
+enum i3c_ccc_test_mode {
+	I3C_CCC_EXIT_TEST_MODE,
+	I3C_CCC_VENDOR_TEST_MODE,
+};
+
+/**
+ * struct i3c_ccc_enttm - payload passed to ENTTM CCC
+ *
+ * @mode: one of the &enum i3c_ccc_test_mode modes
+ *
+ * Information passed to the ENTTM CCC to instruct an I3C device to enter a
+ * specific test mode.
+ */
+struct i3c_ccc_enttm {
+	u8 mode;
+} __packed;
+
+/**
+ * struct i3c_ccc_setda - payload passed to ENTTM CCC
+ *
+ * @mode: one of the &enum i3c_ccc_test_mode modes
+ *
+ * Information passed to the ENTTM CCC to instruct an I3C device to enter a
+ * specific test mode.
+ */
+struct i3c_ccc_setda {
+	u8 addr;
+} __packed;
+
+/**
+ * struct i3c_ccc_getpid - payload passed to GETPID CCC
+ *
+ * @pid: 48 bits PID in big endian
+ */
+struct i3c_ccc_getpid {
+	u8 pid[6];
+} __packed;
+
+/**
+ * struct i3c_ccc_getbcr - payload passed to GETBCR CCC
+ *
+ * @bcr: BCR (Bus Characteristic Register) value
+ */
+struct i3c_ccc_getbcr {
+	u8 bcr;
+} __packed;
+
+/**
+ * struct i3c_ccc_getdcr - payload passed to GETDCR CCC
+ *
+ * @dcr: DCR (Device Characteristic Register) value
+ */
+struct i3c_ccc_getdcr {
+	u8 dcr;
+} __packed;
+
+#define I3C_CCC_STATUS_PENDING_INT(status)	((status) & GENMASK(3, 0))
+#define I3C_CCC_STATUS_PROTOCOL_ERROR		BIT(5)
+#define I3C_CCC_STATUS_ACTIVITY_MODE(status)	\
+	(((status) & GENMASK(7, 6)) >> 6)
+
+/**
+ * struct i3c_ccc_getstatus - payload passed to GETSTATUS CCC
+ *
+ * @status: status of the I3C slave (see I3C_CCC_STATUS_xxx macros for more
+ *	    information).
+ */
+struct i3c_ccc_getstatus {
+	__be16 status;
+} __packed;
+
+/**
+ * struct i3c_ccc_getaccmst - payload passed to GETACCMST CCC
+ *
+ * @newmaster: address of the master taking bus ownership
+ */
+struct i3c_ccc_getaccmst {
+	u8 newmaster;
+} __packed;
+
+/**
+ * struct i3c_ccc_bridged_slave_desc - bridged slave descriptor
+ *
+ * @addr: dynamic address of the bridged device
+ * @id: ID of the slave device behind the bridge
+ */
+struct i3c_ccc_bridged_slave_desc {
+	u8 addr;
+	__be16 id;
+} __packed;
+
+/**
+ * struct i3c_ccc_setbrgtgt - payload passed to SETBRGTGT CCC
+ *
+ * @count: number of bridged slaves
+ * @bslaves: bridged slave descriptors
+ */
+struct i3c_ccc_setbrgtgt {
+	u8 count;
+	struct i3c_ccc_bridged_slave_desc bslaves[0];
+} __packed;
+
+/**
+ * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers
+ */
+enum i3c_sdr_max_data_rate {
+	I3C_SDR_DR_FSCL_MAX,
+	I3C_SDR_DR_FSCL_8MHZ,
+	I3C_SDR_DR_FSCL_6MHZ,
+	I3C_SDR_DR_FSCL_4MHZ,
+	I3C_SDR_DR_FSCL_2MHZ,
+};
+
+/**
+ * enum i3c_tsco - clock to data turn-around
+ */
+enum i3c_tsco {
+	I3C_TSCO_LT_8NS,
+	I3C_TSCO_LT_9NS,
+	I3C_TSCO_LT_10NS,
+	I3C_TSCO_LT_11NS,
+	I3C_TSCO_LT_12NS,
+};
+
+#define I3C_CCC_MAX_SDR_FSCL_MASK	GENMASK(2, 0)
+#define I3C_CCC_MAX_SDR_FSCL(x)		((x) & I3C_CCC_MAX_SDR_FSCL_MASK)
+
+/**
+ * struct i3c_ccc_getmxds - payload passed to GETMXDS CCC
+ *
+ * @maxwr: write limitations
+ * @maxrd: read limitations
+ * @maxrdturn: maximum read turn-around expressed micro-seconds and
+ *	       little-endian formatted
+ */
+struct i3c_ccc_getmxds {
+	u8 maxwr;
+	u8 maxrd;
+	u8 maxrdturn[3];
+} __packed;
+
+#define I3C_CCC_HDR_MODE(mode)		BIT(mode)
+
+/**
+ * struct i3c_ccc_gethdrcap - payload passed to GETHDRCAP CCC
+ *
+ * @modes: bitmap of supported HDR modes
+ */
+struct i3c_ccc_gethdrcap {
+	u8 modes;
+} __packed;
+
+/**
+ * enum i3c_ccc_setxtime_subcmd - SETXTIME sub-commands
+ */
+enum i3c_ccc_setxtime_subcmd {
+	I3C_CCC_SETXTIME_ST = 0x7f,
+	I3C_CCC_SETXTIME_DT = 0xbf,
+	I3C_CCC_SETXTIME_ENTER_ASYNC_MODE0 = 0xdf,
+	I3C_CCC_SETXTIME_ENTER_ASYNC_MODE1 = 0xef,
+	I3C_CCC_SETXTIME_ENTER_ASYNC_MODE2 = 0xf7,
+	I3C_CCC_SETXTIME_ENTER_ASYNC_MODE3 = 0xfb,
+	I3C_CCC_SETXTIME_ASYNC_TRIGGER = 0xfd,
+	I3C_CCC_SETXTIME_TPH = 0x3f,
+	I3C_CCC_SETXTIME_TU = 0x9f,
+	I3C_CCC_SETXTIME_ODR = 0x8f,
+};
+
+/**
+ * struct i3c_ccc_setxtime - payload passed to SETXTIME CCC
+ *
+ * @subcmd: one of the sub-commands ddefined in &enum i3c_ccc_setxtime_subcmd
+ * @data: sub-command payload. Amount of data is determined by
+ *	  &i3c_ccc_setxtime->subcmd
+ */
+struct i3c_ccc_setxtime {
+	u8 subcmd;
+	u8 data[0];
+} __packed;
+
+#define I3C_CCC_GETXTIME_SYNC_MODE	BIT(0)
+#define I3C_CCC_GETXTIME_ASYNC_MODE(x)	BIT((x) + 1)
+#define I3C_CCC_GETXTIME_OVERFLOW	BIT(7)
+
+/**
+ * struct i3c_ccc_getxtime - payload retrieved from GETXTIME CCC
+ *
+ * @supported_modes: bitmap describing supported XTIME modes
+ * @state: current status (enabled mode and overflow status)
+ * @frequency: slave's internal oscillator frequency in 500KHz steps
+ * @inaccuracy: slave's internal oscillator inaccuracy in 0.1% steps
+ */
+struct i3c_ccc_getxtime {
+	u8 supported_modes;
+	u8 state;
+	u8 frequency;
+	u8 inaccuracy;
+} __packed;
+
+/**
+ * struct i3c_ccc_cmd_payload - CCC payload
+ *
+ * @len: payload length
+ * @data: payload data
+ */
+struct i3c_ccc_cmd_payload {
+	u16 len;
+	void *data;
+};
+
+/**
+ * struct i3c_ccc_cmd_dest - CCC command destination
+ *
+ * @addr: can be an I3C device address or the broadcast address if this is a
+ *	  broadcast CCC
+ * @payload: payload to be sent to this device or broadcasted
+ */
+struct i3c_ccc_cmd_dest {
+	u8 addr;
+	struct i3c_ccc_cmd_payload payload;
+};
+
+/**
+ * struct i3c_ccc_cmd - CCC command
+ *
+ * @rnw: true if the CCC should retrieve data from the device. Only valid for
+ *	 unicast commands
+ * @id: CCC command id
+ * @dests: array of destinations and associated payload for this CCC. Most of
+ *	   the time, only one destination is provided
+ * @ndests: number of destinations. Should always be one for broadcast commands
+ */
+struct i3c_ccc_cmd {
+	bool rnw;
+	u8 id;
+	struct i3c_ccc_cmd_dest *dests;
+	int ndests;
+};
+
+#endif /* I3C_CCC_H */
diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h
new file mode 100644
index 000000000000..83958d3a02e2
--- /dev/null
+++ b/include/linux/i3c/device.h
@@ -0,0 +1,321 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ */
+
+#ifndef I3C_DEV_H
+#define I3C_DEV_H
+
+#include <linux/device.h>
+#include <linux/i2c.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+
+/**
+ * enum i3c_hdr_mode - HDR mode ids
+ * @I3C_HDR_DDR: DDR mode
+ * @I3C_HDR_TSP: TSP mode
+ * @I3C_HDR_TSL: TSL mode
+ */
+enum i3c_hdr_mode {
+	I3C_HDR_DDR,
+	I3C_HDR_TSP,
+	I3C_HDR_TSL,
+};
+
+/**
+ * struct i3c_hdr_cmd - I3C HDR command
+ * @mode: HDR mode selected for this command
+ * @code: command opcode
+ * @addr: I3C dynamic address
+ * @ndatawords: number of data words (a word is 16bits wide)
+ * @data: input/output buffer
+ */
+struct i3c_hdr_cmd {
+	enum i3c_hdr_mode mode;
+	u8 code;
+	u8 addr;
+	int ndatawords;
+	union {
+		u16 *in;
+		const u16 *out;
+	} data;
+};
+
+/* Private SDR read transfer */
+#define I3C_PRIV_XFER_READ		BIT(0)
+/*
+ * Instruct the controller to issue a STOP after a specific transfer instead
+ * of a REPEATED START.
+ */
+#define I3C_PRIV_XFER_STOP		BIT(1)
+
+/**
+ * struct i3c_priv_xfer - I3C SDR private transfer
+ * @addr: I3C dynamic address
+ * @len: transfer length in bytes of the transfer
+ * @flags: combination of I3C_PRIV_XFER_xxx flags
+ * @data: input/output buffer
+ */
+struct i3c_priv_xfer {
+	u8 addr;
+	u16 len;
+	u32 flags;
+	struct {
+		void *in;
+		const void *out;
+	} data;
+};
+
+/**
+ * enum i3c_dcr - I3C DCR values
+ * @I3C_DCR_GENERIC_DEVICE: generic I3C device
+ */
+enum i3c_dcr {
+	I3C_DCR_GENERIC_DEVICE = 0,
+};
+
+#define I3C_PID_MANUF_ID(pid)		(((pid) & GENMASK_ULL(47, 33)) >> 33)
+#define I3C_PID_RND_LOWER_32BITS(pid)	(!!((pid) & BIT_ULL(32)))
+#define I3C_PID_RND_VAL(pid)		((pid) & GENMASK_ULL(31, 0))
+#define I3C_PID_PART_ID(pid)		(((pid) & GENMASK_ULL(31, 16)) >> 16)
+#define I3C_PID_INSTANCE_ID(pid)	(((pid) & GENMASK_ULL(15, 12)) >> 12)
+#define I3C_PID_EXTRA_INFO(pid)		((pid) & GENMASK_ULL(11, 0))
+
+#define I3C_BCR_DEVICE_ROLE(bcr)	((bcr) & GENMASK(7, 6))
+#define I3C_BCR_I3C_SLAVE		(0 << 6)
+#define I3C_BCR_I3C_MASTER		(1 << 6)
+#define I3C_BCR_HDR_CAP			BIT(5)
+#define I3C_BCR_BRIDGE			BIT(4)
+#define I3C_BCR_OFFLINE_CAP		BIT(3)
+#define I3C_BCR_IBI_PAYLOAD		BIT(2)
+#define I3C_BCR_IBI_REQ_CAP		BIT(1)
+#define I3C_BCR_MAX_DATA_SPEED_LIM	BIT(0)
+
+/**
+ * struct i3c_device_info - I3C device information
+ * @pid: Provisional ID
+ * @bcr: Bus Characteristic Register
+ * @dcr: Device Characteristic Register
+ * @static_addr: static/I2C address
+ * @dyn_addr: dynamic address
+ * @hdr_cap: supported HDR modes
+ * @max_read_ds: max read speed information
+ * @max_write_ds: max write speed information
+ * @max_ibi_len: max IBI payload length
+ * @max_read_turnaround: max read turn-around time in micro-seconds
+ * @max_read_len: max private SDR read length in bytes
+ * @max_write_len: max private SDR write length in bytes
+ *
+ * These are all basic information that should be advertised by an I3C device.
+ * Some of them are optional depending on the device type and device
+ * capabilities.
+ * For each I3C slave attached to a master with
+ * i3c_master_add_i3c_dev_locked(), the core will send the relevant CCC command
+ * to retrieve these data.
+ */
+struct i3c_device_info {
+	u64 pid;
+	u8 bcr;
+	u8 dcr;
+	u8 static_addr;
+	u8 dyn_addr;
+	u8 hdr_cap;
+	u8 max_read_ds;
+	u8 max_write_ds;
+	u8 max_ibi_len;
+	u32 max_read_turnaround;
+	u16 max_read_len;
+	u16 max_write_len;
+};
+
+/*
+ * I3C device internals are kept hidden from I3C device users. It's just
+ * simpler to refactor things when everything goes through getter/setters, and
+ * I3C device drivers should not have to worry about internal representation
+ * anyway.
+ */
+struct i3c_device;
+
+/* These macros should be used to i3c_device_id entries. */
+#define I3C_MATCH_MANUF_AND_PART (I3C_MATCH_MANUF | I3C_MATCH_PART)
+
+#define I3C_DEVICE(_manufid, _partid, _drvdata)				\
+	{								\
+		.match_flags = I3C_MATCH_MANUF_AND_PART,		\
+		.manuf_id = _manufid,					\
+		.part_id = _partid,					\
+		.data = _drvdata,					\
+	}
+
+#define I3C_DEVICE_EXTRA_INFO(_manufid, _partid, _info, _drvdata)	\
+	{								\
+		.match_flags = I3C_MATCH_MANUF_AND_PART |		\
+			       I3C_MATCH_EXTRA_INFO,			\
+		.manuf_id = _manufid,					\
+		.part_id = _partid,					\
+		.extra_info = _info,					\
+		.data = _drvdata,					\
+	}
+
+#define I3C_CLASS(_dcr, _drvdata)					\
+	{								\
+		.match_flags = I3C_MATCH_DCR,				\
+		.dcr = _dcr,						\
+	}
+
+/**
+ * struct i3c_driver - I3C device driver
+ * @driver: inherit from device_driver
+ * @probe: I3C device probe method
+ * @remove: I3C device remove method
+ * @id_table: I3C device match table. Will be used by the framework to decide
+ *	      which device to bind to this driver
+ */
+struct i3c_driver {
+	struct device_driver driver;
+	int (*probe)(struct i3c_device *dev);
+	int (*remove)(struct i3c_device *dev);
+	const struct i3c_device_id *id_table;
+};
+
+static inline struct i3c_driver *drv_to_i3cdrv(struct device_driver *drv)
+{
+	return container_of(drv, struct i3c_driver, driver);
+}
+
+const struct i3c_device_id *
+i3c_device_match_id(struct i3c_device *i3cdev,
+		    const struct i3c_device_id *id_table);
+
+int i3c_driver_register_with_owner(struct i3c_driver *drv,
+				   struct module *owner);
+void i3c_driver_unregister(struct i3c_driver *drv);
+
+#define i3c_driver_register(__drv)		\
+	i3c_driver_register_with_owner(__drv, THIS_MODULE)
+
+/**
+ * module_i3c_driver() - Register a module providing an I3C driver
+ * @__drv: the I3C driver to register
+ *
+ * Provide generic init/exit functions that simply register/unregister an I3C
+ * driver.
+ * Should be used by any driver that does not require extra init/cleanup steps.
+ */
+#define module_i3c_driver(__drv)		\
+	module_driver(__drv, i3c_driver_register, i3c_driver_unregister)
+
+/**
+ * i3c_i2c_driver_register() - Register an i2c and an i3c driver
+ * @i3cdrv: the I3C driver to register
+ * @i2cdrv: the I2C driver to register
+ *
+ * This function registers both @i2cdev and @i3cdev, and fails if one of these
+ * registrations fails. This is mainly useful for devices that support both I2C
+ * and I3C modes.
+ * Note that when CONFIG_I3C is not enabled, this function only registers the
+ * I2C driver.
+ *
+ * Return: 0 if both registrations succeeds, a negative error code otherwise.
+ */
+static inline int i3c_i2c_driver_register(struct i3c_driver *i3cdrv,
+					  struct i2c_driver *i2cdrv)
+{
+	int ret;
+
+	ret = i2c_add_driver(i2cdrv);
+	if (ret || !IS_ENABLED(CONFIG_I3C))
+		return ret;
+
+	ret = i3c_driver_register(i3cdrv);
+	if (ret)
+		i2c_del_driver(i2cdrv);
+
+	return ret;
+}
+
+/**
+ * i3c_i2c_driver_unregister() - Unregister an i2c and an i3c driver
+ * @i3cdrv: the I3C driver to register
+ * @i2cdrv: the I2C driver to register
+ *
+ * This function unregisters both @i3cdrv and @i2cdrv.
+ * Note that when CONFIG_I3C is not enabled, this function only unregisters the
+ * @i2cdrv.
+ */
+static inline void i3c_i2c_driver_unregister(struct i3c_driver *i3cdrv,
+					     struct i2c_driver *i2cdrv)
+{
+	if (IS_ENABLED(CONFIG_I3C))
+		i3c_driver_unregister(i3cdrv);
+
+	i2c_del_driver(i2cdrv);
+}
+
+/**
+ * module_i3c_i2c_driver() - Register a module providing an I3C and an I2C
+ *			     driver
+ * @__i3cdrv: the I3C driver to register
+ * @__i2cdrv: the I3C driver to register
+ *
+ * Provide generic init/exit functions that simply register/unregister an I3C
+ * and an I2C driver.
+ * This macro can be used even if CONFIG_I3C is disabled, in this case, only
+ * the I2C driver will be registered.
+ * Should be used by any driver that does not require extra init/cleanup steps.
+ */
+#define module_i3c_i2c_driver(__i3cdrv, __i2cdrv)	\
+	module_driver(__i3cdrv,				\
+		      i3c_i2c_driver_register,		\
+		      i3c_i2c_driver_unregister)
+
+int i3c_device_do_priv_xfers(struct i3c_device *dev,
+			     struct i3c_priv_xfer *xfers,
+			     int nxfers);
+int i3c_device_send_hdr_cmds(struct i3c_device *dev,
+			     struct i3c_hdr_cmd *cmds,
+			     int ncmds);
+
+void i3c_device_get_info(struct i3c_device *dev, struct i3c_device_info *info);
+
+struct i3c_ibi_payload {
+	unsigned int len;
+	const void *data;
+};
+
+/**
+ * struct i3c_ibi_setup - IBI setup object
+ * @max_payload_len: maximum length of the payload associated to an IBI. If one
+ *		     IBI appears to have a payload that is bigger than this
+ *		     number, the IBI will be rejected.
+ * @num_slots: number of pre-allocated IBI slots. This should be chosen so that
+ *	       the system never runs out of IBI slots, otherwise you'll lose
+ *	       IBIs.
+ * @handler: IBI handler, every time an IBI is received. This handler is called
+ *	     in a workqueue context. It is allowed to sleep and send new
+ *	     messages on the bus, though it's recommended to keep the
+ *	     processing done there as fast as possible to avoid delaying
+ *	     processing of other queued on the same workqueue.
+ *
+ * Temporary structure used to pass information to i3c_device_request_ibi().
+ * This object can be allocated on the stack since i3c_device_request_ibi()
+ * copies every bit of information and do not use it after
+ * i3c_device_request_ibi() has returned.
+ */
+struct i3c_ibi_setup {
+	unsigned int max_payload_len;
+	unsigned int num_slots;
+	void (*handler)(struct i3c_device *dev,
+			const struct i3c_ibi_payload *payload);
+};
+
+int i3c_device_request_ibi(struct i3c_device *dev,
+			   const struct i3c_ibi_setup *setup);
+void i3c_device_free_ibi(struct i3c_device *dev);
+int i3c_device_enable_ibi(struct i3c_device *dev);
+int i3c_device_disable_ibi(struct i3c_device *dev);
+
+#endif /* I3C_DEV_H */
diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
new file mode 100644
index 000000000000..7ec9a4821bac
--- /dev/null
+++ b/include/linux/i3c/master.h
@@ -0,0 +1,564 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ */
+
+#ifndef I3C_MASTER_H
+#define I3C_MASTER_H
+
+#include <linux/i2c.h>
+#include <linux/i3c/ccc.h>
+#include <linux/i3c/device.h>
+#include <linux/spinlock.h>
+
+#define I3C_HOT_JOIN_ADDR		0x2
+#define I3C_BROADCAST_ADDR		0x7e
+#define I3C_MAX_ADDR			GENMASK(6, 0)
+
+struct i3c_master_controller;
+struct i3c_bus;
+
+/**
+ * struct i3c_i2c_dev - I3C/I2C common information
+ * @node: node element used to insert the device into the I2C or I3C device
+ *	  list
+ * @bus: I3C bus this device is connected to
+ * @master: I3C master that instantiated this device. Will be used to send
+ *	    I2C/I3C frames on the bus
+ * @master_priv: master private data assigned to the device. Can be used to
+ *		 add master specific information
+ *
+ * This structure is describing common I3C/I2C dev information.
+ */
+struct i3c_i2c_dev {
+	struct list_head node;
+	struct i3c_bus *bus;
+	struct i3c_master_controller *master;
+	void *master_priv;
+};
+
+#define I3C_LVR_I2C_INDEX_MASK		GENMASK(7, 5)
+#define I3C_LVR_I2C_INDEX(x)		((x) << 5)
+#define I3C_LVR_I2C_FM_MODE		BIT(4)
+
+#define I2C_MAX_ADDR			GENMASK(9, 0)
+
+/**
+ * struct i2c_device - I2C device object
+ * @common: inherit common I3C/I2C description
+ * @info: I2C board info used to instantiate the I2C device. If you are
+ *	  using DT to describe your hardware, this will be filled for you
+ * @client: I2C client object created by the I2C framework. This will only
+ *	    be valid after i3c_master_register() returns
+ * @lvr: Legacy Virtual Register value as described in the I3C specification
+ *
+ * I2C device object. Note that the real I2C device is represented by
+ * i2c_device->client, but we need extra information to handle the device when
+ * it's connected to an I3C bus, hence the &struct i2c_device wrapper.
+ *
+ * The I2C framework is not impacted by this new representation.
+ */
+struct i2c_device {
+	struct i3c_i2c_dev common;
+	struct i2c_board_info info;
+	struct i2c_client *client;
+	u8 lvr;
+};
+
+/**
+ * struct i3c_ibi_slot - I3C IBI (In-Band Interrupt) slot
+ * @work: work associated to this slot. The IBI handler will be called from
+ *	  there
+ * @dev: the I3C device that has generated this IBI
+ * @len: length of the payload associated to this IBI
+ * @data: payload buffer
+ *
+ * An IBI slot is an object pre-allocated by the controller and used when an
+ * IBI comes in.
+ * Every time an IBI comes in, the I3C master driver should find a free IBI
+ * slot in its IBI slot pool, retrieve the IBI payload and queue the IBI using
+ * i3c_device_queue_ibi().
+ *
+ * How IBI slots are allocated is left to the I3C master driver, though, for
+ * simple kmalloc-based allocation, the generic IBI slot pool can be used.
+ */
+struct i3c_ibi_slot {
+	struct work_struct work;
+	struct i3c_device *dev;
+	unsigned int len;
+	void *data;
+};
+
+/**
+ * struct i3c_device_ibi_info - IBI information attached to a specific device
+ * @all_ibis_handled: used to be informed when no more IBIs are waiting to be
+ *		      processed. Used by i3c_device_disable_ibi() to wait for
+ *		      all IBIs to be dequeued
+ * @pending_ibis: count the number of pending IBIs. Each pending IBI has its
+ *		  work element queued to the controller workqueue
+ * @max_payload_len: maximum payload length for an IBI coming from this device.
+ *		     this value is specified when calling
+ *		     i3c_device_request_ibi() and should not change at run
+ *		     time. All messages IBIs exceeding this limit should be
+ *		     rejected by the master
+ * @enabled: reflect the IBI status
+ * @handler: IBI handler specified at i3c_device_request_ibi() call time. This
+ *	     handler will be called from the controller workqueue, and as such
+ *	     is allowed to sleep (though it is recommended to process the IBI
+ *	     as fast as possible to not stall processing of other IBIs queued
+ *	     on the same workqueue).
+ *	     New I3C messages can be sent from the IBI handler
+ *
+ * The &struct_i3c_device_ibi_info object is allocated when
+ * i3c_device_request_ibi() is called and attached to a specific device. This
+ * object is here to manage IBIs coming from a specific I3C device.
+ *
+ * Note that this structure is the generic view of the IBI management
+ * infrastructure. I3C master drivers may have their own internal
+ * representation which they can associate to the device using
+ * controller-private data.
+ */
+struct i3c_device_ibi_info {
+	struct completion all_ibis_handled;
+	atomic_t pending_ibis;
+	unsigned int max_payload_len;
+	bool enabled;
+	void (*handler)(struct i3c_device *dev,
+			const struct i3c_ibi_payload *payload);
+};
+
+/**
+ * struct i3c_device - I3C device object
+ * @common: inherit common I3C/I2C description
+ * @dev: device object to register the I3C dev to the device model
+ * @new: true if the device has not yet been registered to the device model.
+ *	 Will be set to false after device_add() is called on this device
+ *	 even if device_add() fails
+ * @info: I3C device information. Will be automatically filled when you create
+ *	  your device with i3c_master_add_i3c_dev_locked()
+ * @ibi_lock: lock used to protect the &struct_i3c_device->ibi
+ * @ibi: IBI info attached to a device. Should be NULL until
+ *	 i3c_device_request_ibi() is called
+ *
+ * I3C device object. Every I3C devs on the I3C bus are represented, including
+ * I3C masters. For each of them, we have an instance of &struct i3c_device.
+ */
+struct i3c_device {
+	struct i3c_i2c_dev common;
+	struct device dev;
+	bool new;
+	struct i3c_device_info info;
+	struct mutex ibi_lock;
+	struct i3c_device_ibi_info *ibi;
+};
+
+/*
+ * The I3C specification says the maximum number of devices connected on the
+ * bus is 11, but this number depends on external parameters like trace length,
+ * capacitive load per Device, and the types of Devices present on the Bus.
+ * I3C master can also have limitations, so this number is just here as a
+ * reference and should be adjusted on a per-controller/per-board basis.
+ */
+#define I3C_BUS_MAX_DEVS		11
+
+#define I3C_BUS_MAX_I3C_SCL_RATE	12900000
+#define I3C_BUS_TYP_I3C_SCL_RATE	12500000
+#define I3C_BUS_I2C_FM_PLUS_SCL_RATE	1000000
+#define I3C_BUS_I2C_FM_SCL_RATE		400000
+#define I3C_BUS_TLOW_OD_MIN_NS		200
+
+/**
+ * enum i3c_bus_mode - I3C bus mode
+ * @I3C_BUS_MODE_PURE: only I3C devices are connected to the bus. No limitation
+ *		       expected
+ * @I3C_BUS_MODE_MIXED_FAST: I2C devices with 50ns spike filter are present on
+ *			     the bus. The only impact in this mode is that the
+ *			     high SCL pulse has to stay below 50ns to trick I2C
+ *			     devices when transmitting I3C frames
+ * @I3C_BUS_MODE_MIXED_SLOW: I2C devices without 50ns spike filter are present
+ *			     on the bus
+ */
+enum i3c_bus_mode {
+	I3C_BUS_MODE_PURE,
+	I3C_BUS_MODE_MIXED_FAST,
+	I3C_BUS_MODE_MIXED_SLOW,
+};
+
+/**
+ * enum i3c_addr_slot_status - I3C address slot status
+ * @I3C_ADDR_SLOT_FREE: address is free
+ * @I3C_ADDR_SLOT_RSVD: address is reserved
+ * @I3C_ADDR_SLOT_I2C_DEV: address is assigned to an I2C device
+ * @I3C_ADDR_SLOT_I3C_DEV: address is assigned to an I3C device
+ * @I3C_ADDR_SLOT_STATUS_MASK: address slot mask
+ *
+ * On an I3C bus, addresses are assigned dynamically, and we need to know which
+ * addresses are free to use and which ones are already assigned.
+ *
+ * Addresses marked as reserved are those reserved by the I3C protocol
+ * (broadcast address, ...).
+ */
+enum i3c_addr_slot_status {
+	I3C_ADDR_SLOT_FREE,
+	I3C_ADDR_SLOT_RSVD,
+	I3C_ADDR_SLOT_I2C_DEV,
+	I3C_ADDR_SLOT_I3C_DEV,
+	I3C_ADDR_SLOT_STATUS_MASK = 3,
+};
+
+/**
+ * struct i3c_bus - I3C bus object
+ * @dev: device to be registered to the device-model
+ * @cur_master: I3C master currently driving the bus. Since I3C is multi-master
+ *		this can change over the time. Will be used to let a master
+ *		know whether it needs to request bus ownership before sending
+ *		a frame or not
+ * @id: bus ID. Assigned by the framework when register the bus
+ * @addrslots: a bitmap with 2-bits per-slot to encode the address status and
+ *	       ease the DAA (Dynamic Address Assignment) procedure (see
+ *	       &enum i3c_addr_slot_status)
+ * @mode: bus mode (see &enum i3c_bus_mode)
+ * @scl_rate: SCL signal rate for I3C and I2C mode
+ * @devs: 2 lists containing all I3C/I2C devices connected to the bus
+ * @lock: read/write lock on the bus. This is needed to protect against
+ *	  operations that have an impact on the whole bus and the devices
+ *	  connected to it. For example, when asking slaves to drop their
+ *	  dynamic address (RSTDAA CCC), we need to make sure no one is trying
+ *	  to send I3C frames to these devices.
+ *	  Note that this lock does not protect against concurrency between
+ *	  devices: several drivers can send different I3C/I2C frames through
+ *	  the same master in parallel. This is the responsibility of the
+ *	  master to guarantee that frames are actually sent sequentially and
+ *	  not interlaced
+ *
+ * The I3C bus is represented with its own object and not implicitly described
+ * by the I3C master to cope with the multi-master functionality, where one bus
+ * can be shared amongst several masters, each of them requesting bus ownership
+ * when they need to.
+ */
+struct i3c_bus {
+	struct device dev;
+	struct i3c_device *cur_master;
+	int id;
+	unsigned long addrslots[((I2C_MAX_ADDR + 1) * 2) / BITS_PER_LONG];
+	enum i3c_bus_mode mode;
+	struct {
+		unsigned long i3c;
+		unsigned long i2c;
+	} scl_rate;
+	struct {
+		struct list_head i3c;
+		struct list_head i2c;
+	} devs;
+	struct rw_semaphore lock;
+};
+
+static inline struct i3c_device *dev_to_i3cdev(struct device *dev)
+{
+	return container_of(dev, struct i3c_device, dev);
+}
+
+struct i3c_master_controller;
+
+/**
+ * struct i3c_master_controller_ops - I3C master methods
+ * @bus_init: hook responsible for the I3C bus initialization. This
+ *	      initialization should follow the steps described in the I3C
+ *	      specification. This hook is called with the bus lock held in
+ *	      write mode, which means all _locked() helpers can safely be
+ *	      called from there
+ * @bus_cleanup: cleanup everything done in
+ *		 &i3c_master_controller_ops->bus_init(). This function is
+ *		 optional and should only be implemented if
+ *		 &i3c_master_controller_ops->bus_init() attached private data
+ *		 to I3C/I2C devices. This hook is called with the bus lock
+ *		 held in write mode, which means all _locked() helpers can
+ *		 safely be called from there
+ * @supports_ccc_cmd: should return true if the CCC command is supported, false
+ *		      otherwise
+ * @send_ccc_cmd: send a CCC command
+ * @send_hdr_cmds: send one or several HDR commands. If there is more than one
+ *		   command, they should ideally be sent in the same HDR
+ *		   transaction
+ * @priv_xfers: do one or several private I3C SDR transfers
+ * @i2c_xfers: do one or several I2C transfers
+ * @request_ibi: attach an IBI handler to an I3C device. This implies defining
+ *		 an IBI handler and the constraints of the IBI (maximum payload
+ *		 length and number of pre-allocated slots).
+ *		 Some controllers support less IBI-capable devices than regular
+ *		 devices, so this method might return -%EBUSY if there's no
+ *		 more space for an extra IBI registration
+ * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI
+ *	      should have been disabled with ->disable_irq() prior to that
+ * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called
+ *		prior to ->enable_ibi(). The controller should first enable
+ *		the IBI on the controller end (for example, unmask the hardware
+ *		IRQ) and then send the ENEC CCC command (with the IBI flag set)
+ *		to the I3C device
+ * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI
+ *		 flag set and then deactivate the hardware IRQ on the
+ *		 controller end
+ * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been
+ *		      processed by its handler. The IBI slot should be put back
+ *		      in the IBI slot pool so that the controller can re-use it
+ *		      for a future IBI
+ *
+ * One of the most important hooks in these ops is
+ * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of
+ * things that should be done in &i3c_master_controller_ops->bus_init():
+ *
+ * 1) call i3c_master_set_info() with all information describing the master
+ * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC
+ *    with i3c_master_rstdaa_locked()
+ * 3) ask all slaves to disable IBIs using i3c_master_disec_locked()
+ * 4) start a DDA procedure by sending the ENTDAA CCC with
+ *    i3c_master_entdaa_locked(), or using the internal DAA logic provided by
+ *    your controller
+ * 5) assign a dynamic address to each I3C device discovered during DAA and
+ *    for each of them, call i3c_master_add_i3c_dev_locked()
+ * 6) propagate device table to secondary masters by calling
+ *    i3c_master_defslvs_locked()
+ *
+ * Note that these steps do not include all controller specific initialization.
+ */
+struct i3c_master_controller_ops {
+	int (*bus_init)(struct i3c_master_controller *master);
+	void (*bus_cleanup)(struct i3c_master_controller *master);
+	bool (*supports_ccc_cmd)(struct i3c_master_controller *master,
+				 const struct i3c_ccc_cmd *cmd);
+	int (*send_ccc_cmd)(struct i3c_master_controller *master,
+			    struct i3c_ccc_cmd *cmd);
+	int (*send_hdr_cmds)(struct i3c_master_controller *master,
+			     const struct i3c_hdr_cmd *cmds,
+			     int ncmds);
+	int (*priv_xfers)(struct i3c_master_controller *master,
+			  const struct i3c_priv_xfer *xfers,
+			  int nxfers);
+	int (*i2c_xfers)(struct i3c_master_controller *master,
+			 const struct i2c_msg *xfers, int nxfers);
+	int (*request_ibi)(struct i3c_master_controller *master,
+			   struct i3c_device *dev,
+			   const struct i3c_ibi_setup *req);
+	void (*free_ibi)(struct i3c_master_controller *master,
+			 struct i3c_device *dev);
+	int (*enable_ibi)(struct i3c_master_controller *master,
+			  struct i3c_device *dev);
+	int (*disable_ibi)(struct i3c_master_controller *master,
+			   struct i3c_device *dev);
+	void (*recycle_ibi_slot)(struct i3c_master_controller *master,
+				 struct i3c_device *dev,
+				 struct i3c_ibi_slot *slot);
+};
+
+/**
+ * struct i3c_master_controller - I3C master controller object
+ * @parent: parent device that instantiated this master
+ * @this: an I3C device object representing this master. This device will be
+ *	  added to the list of I3C devs available on the bus
+ * @i2c: I2C adapter used for backward compatibility. This adapter is
+ *	 registered to the I2C subsystem to be as transparent as possible to
+ *	 existing I2C drivers
+ * @ops: master operations. See &struct i3c_master_controller_ops
+ * @secondary: true if the master is a secondary master
+ * @bus: I3C bus object created by this master
+ * @wq: workqueue used to execute IBI handlers. Can also be used by master
+ *	drivers if they need to postpone operations that need to take place
+ *	in a thread context. Typical examples are Hot Join processing which
+ *	requires taking the bus lock in maintenance, which in turn, can only
+ *	be done from a sleep-able context
+ *
+ * A &struct i3c_master_controller has to be registered to the I3C subsystem
+ * through i3c_master_register(). None of &struct i3c_master_controller fields
+ * should be set manually, just pass appropriate values to
+ * i3c_master_register().
+ */
+struct i3c_master_controller {
+	struct device *parent;
+	struct i3c_device *this;
+	struct i2c_adapter i2c;
+	const struct i3c_master_controller_ops *ops;
+	bool secondary;
+	struct i3c_bus *bus;
+	struct workqueue_struct *wq;
+};
+
+/**
+ * i3c_bus_for_each_i2cdev() - iterate over all I2C devices present on the bus
+ * @bus: the I3C bus
+ * @i2cdev: an I2C device updated to point to the current device at each loop
+ *	    iteration
+ *
+ * Iterate over all I2C devs present on the bus.
+ */
+#define i3c_bus_for_each_i2cdev(bus, i2cdev)				\
+	list_for_each_entry(i2cdev, &(bus)->devs.i2c, common.node)
+
+/**
+ * i3c_bus_for_each_i3cdev() - iterate over all I3C devices present on the bus
+ * @bus: the I3C bus
+ * @i3cdev: an I3C device updated to point to the current device at each loop
+ *	    iteration
+ *
+ * Iterate over all I3C devs present on the bus.
+ */
+#define i3c_bus_for_each_i3cdev(bus, i3cdev)				\
+	list_for_each_entry(i3cdev, &(bus)->devs.i3c, common.node)
+
+void i3c_bus_maintenance_lock(struct i3c_bus *bus);
+void i3c_bus_maintenance_unlock(struct i3c_bus *bus);
+void i3c_bus_normaluse_lock(struct i3c_bus *bus);
+void i3c_bus_normaluse_unlock(struct i3c_bus *bus);
+
+int i3c_master_send_hdr_cmds(struct i3c_master_controller *master,
+			     const struct i3c_hdr_cmd *cmds,
+			     int ncmds);
+int i3c_master_do_priv_xfers(struct i3c_master_controller *master,
+			     const struct i3c_priv_xfer *xfers,
+			     int nxfers);
+int i3c_master_do_i2c_xfers(struct i3c_master_controller *master,
+			    const struct i2c_msg *xfers,
+			    int nxfers);
+
+int i3c_master_disec_locked(struct i3c_master_controller *master, u8 addr,
+			    const struct i3c_ccc_events *evts);
+int i3c_master_enec_locked(struct i3c_master_controller *master, u8 addr,
+			   const struct i3c_ccc_events *evts);
+int i3c_master_rstdaa_locked(struct i3c_master_controller *master, u8 addr);
+int i3c_master_entdaa_locked(struct i3c_master_controller *master);
+int i3c_master_defslvs_locked(struct i3c_master_controller *master);
+
+int i3c_master_get_free_addr(struct i3c_master_controller *master,
+			     u8 start_addr);
+
+struct i3c_device *
+i3c_master_add_i3c_dev_locked(struct i3c_master_controller *master, u8 addr);
+void i3c_master_register_new_i3c_devs(struct i3c_master_controller *master);
+
+int i3c_master_set_info(struct i3c_master_controller *master,
+			const struct i3c_device_info *info);
+
+int i3c_master_register(struct i3c_master_controller *master,
+			struct device *parent,
+			const struct i3c_master_controller_ops *ops,
+			bool secondary);
+int i3c_master_unregister(struct i3c_master_controller *master);
+
+/**
+ * i3c_device_get_master_data() - get master private data attached to an I3C
+ *				  device
+ * @dev: the I3C dev to attach private data to
+ *
+ * Return: the private data previously attached with
+ *	   i3c_device_set_master_data() or NULL if no data has been attached
+ *	   to the device.
+ */
+static inline void *i3c_device_get_master_data(const struct i3c_device *dev)
+{
+	return dev->common.master_priv;
+}
+
+/**
+ * i3c_device_set_master_data() - attach master private data to an I3C device
+ * @dev: the I3C dev to attach private data to
+ * @data: private data
+ *
+ * This functions allows a master controller to attach per-device private data
+ * which can then be retrieved with i3c_device_get_master_data().
+ *
+ * Attaching private data to a device is usually done just after calling
+ * i3c_master_add_i3c_dev_locked().
+ */
+static inline void i3c_device_set_master_data(struct i3c_device *dev,
+					      void *data)
+{
+	dev->common.master_priv = data;
+}
+
+/**
+ * i2c_device_get_master_data() - get master private data attached to an I2C
+ *				  device
+ * @dev: the I2C dev to attach private data to
+ *
+ * Return: the private data previously attached with
+ *	   i2c_device_set_master_data() or NULL if no data has been attached
+ *	   to the device.
+ */
+static inline void *i2c_device_get_master_data(const struct i2c_device *dev)
+{
+	return dev->common.master_priv;
+}
+
+/**
+ * i2c_device_set_master_data() - attach master private data to an I2C device
+ * @dev: the I2C dev to attach private data to
+ * @data: private data
+ *
+ * This functions allows a master controller to attach per-device private data
+ * which can then be retrieved with i2c_device_get_master_data().
+ *
+ * Attaching private data to a device is usually done during
+ * &master_controller_ops->bus_init(), by iterating over all I2C devices
+ * instantiated by the core (using i3c_bus_for_each_i2cdev()).
+ */
+static inline void i2c_device_set_master_data(struct i2c_device *dev,
+					      void *data)
+{
+	dev->common.master_priv = data;
+}
+
+/**
+ * i3c_device_get_master() - get master used to communicate with a device
+ * @dev: I3C dev
+ *
+ * Return: the master controller driving @dev
+ */
+static inline struct i3c_master_controller *
+i3c_device_get_master(struct i3c_device *dev)
+{
+	return dev->common.master;
+}
+
+/**
+ * i3c_master_get_bus() - get the bus attached to a master
+ * @master: master object
+ *
+ * Return: the I3C bus @master is connected to
+ */
+static inline struct i3c_bus *
+i3c_master_get_bus(struct i3c_master_controller *master)
+{
+	return master->bus;
+}
+
+/**
+ * i3c_device_get_bus() - get the bus attached to a device
+ * @dev: an I3C device
+ *
+ * Return: the I3C bus @dev is connected to
+ */
+static inline struct i3c_bus *i3c_device_get_bus(struct i3c_device *dev)
+{
+	return i3c_master_get_bus(i3c_device_get_master(dev));
+}
+
+struct i3c_generic_ibi_pool;
+
+void i3c_device_init_ibi_slot(struct i3c_device *dev,
+			      struct i3c_ibi_slot *slot);
+struct i3c_generic_ibi_pool *
+i3c_generic_ibi_alloc_pool(struct i3c_device *dev,
+			   const struct i3c_ibi_setup *req);
+void i3c_generic_ibi_free_pool(struct i3c_generic_ibi_pool *pool);
+
+struct i3c_ibi_slot *
+i3c_generic_ibi_get_free_slot(struct i3c_generic_ibi_pool *pool);
+void i3c_generic_ibi_recycle_slot(struct i3c_generic_ibi_pool *pool,
+				  struct i3c_ibi_slot *slot);
+
+void i3c_device_queue_ibi(struct i3c_device *dev, struct i3c_ibi_slot *slot);
+
+struct i3c_ibi_slot *i3c_device_ibi_get_free_slot(struct i3c_device *dev);
+
+#endif /* I3C_MASTER_H */
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index abb6dc2ebbf8..e59da92d8ac9 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -442,6 +442,23 @@ struct pci_epf_device_id {
 	kernel_ulong_t driver_data;
 };
 
+/* i3c */
+
+#define I3C_MATCH_DCR			BIT(0)
+#define I3C_MATCH_MANUF			BIT(1)
+#define I3C_MATCH_PART			BIT(2)
+#define I3C_MATCH_EXTRA_INFO		BIT(3)
+
+struct i3c_device_id {
+	__u8 match_flags;
+	__u8 dcr;
+	__u16 manuf_id;
+	__u16 part_id;
+	__u16 extra_info;
+
+	const void *data;
+};
+
 /* spi */
 
 #define SPI_NAME_SIZE	32
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCH v2 3/7] docs: driver-api: Add I3C documentation
  2017-12-14 15:16 [PATCH v2 0/7] Add the I3C subsystem Boris Brezillon
  2017-12-14 15:16 ` [PATCH v2 1/7] i2c: Export of_i2c_get_board_info() Boris Brezillon
  2017-12-14 15:16 ` [PATCH v2 2/7] i3c: Add core I3C infrastructure Boris Brezillon
@ 2017-12-14 15:16 ` Boris Brezillon
  2017-12-14 15:16 ` [PATCH v2 4/7] i3c: Add sysfs ABI spec Boris Brezillon
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 50+ messages in thread
From: Boris Brezillon @ 2017-12-14 15:16 UTC (permalink / raw)
  To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij,
	Boris Brezillon

Add the I3C documentation describing the protocol, the master driver API
and the device driver API.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Changes in v2:
- Moved out of patch "i3c: Add core I3C infrastructure"
- Add link to the I3C spec
- Move rst files in Documentation/driver-api/i3c/
---
 Documentation/driver-api/i3c/conf.py               |  10 +
 Documentation/driver-api/i3c/device-driver-api.rst |   7 +
 Documentation/driver-api/i3c/index.rst             |   9 +
 Documentation/driver-api/i3c/master-driver-api.rst |   8 +
 Documentation/driver-api/i3c/protocol.rst          | 201 +++++++++++++++++++++
 Documentation/driver-api/index.rst                 |   1 +
 6 files changed, 236 insertions(+)
 create mode 100644 Documentation/driver-api/i3c/conf.py
 create mode 100644 Documentation/driver-api/i3c/device-driver-api.rst
 create mode 100644 Documentation/driver-api/i3c/index.rst
 create mode 100644 Documentation/driver-api/i3c/master-driver-api.rst
 create mode 100644 Documentation/driver-api/i3c/protocol.rst

diff --git a/Documentation/driver-api/i3c/conf.py b/Documentation/driver-api/i3c/conf.py
new file mode 100644
index 000000000000..5a20832d59a7
--- /dev/null
+++ b/Documentation/driver-api/i3c/conf.py
@@ -0,0 +1,10 @@
+# -*- coding: utf-8; mode: python -*-
+
+project = "Linux I3C Subsystem"
+
+tags.add("subproject")
+
+latex_documents = [
+    ('index', 'i3c.tex', project,
+     'The kernel development community', 'manual'),
+]
diff --git a/Documentation/driver-api/i3c/device-driver-api.rst b/Documentation/driver-api/i3c/device-driver-api.rst
new file mode 100644
index 000000000000..63c843f148a6
--- /dev/null
+++ b/Documentation/driver-api/i3c/device-driver-api.rst
@@ -0,0 +1,7 @@
+=====================
+I3C device driver API
+=====================
+
+.. kernel-doc:: include/linux/i3c/device.h
+
+.. kernel-doc:: drivers/i3c/device.c
diff --git a/Documentation/driver-api/i3c/index.rst b/Documentation/driver-api/i3c/index.rst
new file mode 100644
index 000000000000..9c439220439d
--- /dev/null
+++ b/Documentation/driver-api/i3c/index.rst
@@ -0,0 +1,9 @@
+=============
+I3C subsystem
+=============
+
+.. toctree::
+
+   protocol
+   device-driver-api
+   master-driver-api
diff --git a/Documentation/driver-api/i3c/master-driver-api.rst b/Documentation/driver-api/i3c/master-driver-api.rst
new file mode 100644
index 000000000000..017e7711cdf7
--- /dev/null
+++ b/Documentation/driver-api/i3c/master-driver-api.rst
@@ -0,0 +1,8 @@
+================================
+I3C master controller driver API
+================================
+
+.. kernel-doc:: drivers/i3c/master.c
+
+.. kernel-doc:: include/linux/i3c/master.h
+
diff --git a/Documentation/driver-api/i3c/protocol.rst b/Documentation/driver-api/i3c/protocol.rst
new file mode 100644
index 000000000000..891c4f50c472
--- /dev/null
+++ b/Documentation/driver-api/i3c/protocol.rst
@@ -0,0 +1,201 @@
+============
+I3C protocol
+============
+
+Disclaimer
+==========
+
+This chapter will focus on aspects that matter to software developers. For
+everything hardware related (like how things are transmitted on the bus, how
+collisions are prevented, ...) please have a look at the I3C specification.
+
+This document is just a brief introduction to the I3C protocol and the concepts
+it brings on the table. If you need more information, please refer to the MIPI
+I3C specification (can be downloaded here
+http://resources.mipi.org/mipi-i3c-v1-download).
+
+Introduction
+============
+
+The I3C (pronounced 'eye-three-see') is a MIPI standardized protocol designed
+to overcome I2C limitations (limited speed, external signals needed for
+interrupts, no automatic detection of the devices connected to the bus, ...)
+while remaining power-efficient.
+
+I3C Bus
+=======
+
+An I3C bus is made of several I3C devices and possibly some I2C devices as
+well, but let's focus on I3C devices for now.
+
+An I3C device on the I3C bus can have one of the following roles:
+
+* Master: the device is driving the bus. It's the one in charge of initiating
+  transactions or deciding who is allowed to talk on the bus (slave generated
+  events are possible in I3C, see below).
+* Slave: the device acts as a slave, and is not able to send frames to another
+  slave on the bus. The device can still send events to the master on
+  its own initiative if the master allowed it.
+
+I3C is a multi-master protocol, so there might be several masters on a bus,
+though only one device can act as a master at a given time. In order to gain
+bus ownership, a master has to follow a specific procedure.
+
+Each device on the I3C bus has to be assigned a dynamic address to be able to
+communicate. Until this is done, the device should only respond to a limited
+set of commands. If it has a static address (also called legacy I2C address),
+the device can reply to I2C transfers.
+
+In addition to these per-device addresses, the protocol defines a broadcast
+address in order to address all devices on the bus.
+
+Once a dynamic address has been assigned to a device, this address will be used
+for any direct communication with the device. Note that even after being
+assigned a dynamic address, the device should still process broadcast messages.
+
+I3C Device discovery
+====================
+
+The I3C protocol defines a mechanism to automatically discover devices present
+on the bus, their capabilities and the functionalities they provide. In this
+regard I3C is closer to a discoverable bus like USB than it is to I2C or SPI.
+
+The discovery mechanism is called DAA (Dynamic Address Assignment), because it
+not only discovers devices but also assigns them a dynamic address.
+
+During DAA, each I3C device reports 3 important things:
+
+* BCR: Bus Characteristic Register. This 8-bit register describes the device bus
+  related capabilities
+* DCR: Device Characteristic Register. This 8-bit register describes the
+  functionalities provided by the device
+* Provisional ID: A 48-bit unique identifier. On a given bus there should be no
+  Provisional ID collision, otherwise the discovery mechanism may fail.
+
+I3C slave events
+================
+
+The I3C protocol allows slaves to generate events on their own, and thus allows
+them to take temporary control of the bus.
+
+This mechanism is called IBI for In Band Interrupts, and as stated in the name,
+it allows devices to generate interrupts without requiring an external signal.
+
+During DAA, each device on the bus has been assigned an address, and this
+address will serve as a priority identifier to determine who wins if 2 different
+devices are generating an interrupt at the same moment on the bus (the lower the
+dynamic address the higher the priority).
+
+Masters are allowed to inhibit interrupts if they want to. This inhibition
+request can be broadcasted (applies to all devices) or sent to a specific
+device.
+
+I3C Hot-Join
+============
+
+The Hot-Join mechanism is similart to USB hotplug. This mechanism allows
+slaves to join the bus after it has been initialized by the master.
+
+This covers the following use cases:
+
+* the device is not powered when the bus is probed
+* the device is hotplugged on the bus through an extension board
+
+This mechanism is relying on slave events to inform the master that a new
+device joined the bus and is waiting for a dynamic address.
+
+The master is then free to address the request as it wishes: ignore it or
+assign a dynamic address to the slave.
+
+I3C transfer types
+==================
+
+If you omit SMBus (which is just a standardization on how to access registers
+exposed by I2C devices), I2C has only one transfer type.
+
+I3C defines 3 different classes of transfer in addition to I2C transfers which
+are here for backward compatibility with I2C devices.
+
+I3C CCC commands
+----------------
+
+CCC (Common Command Code) commands are meant to be used for anything that is
+related to bus management and all features that are common to a set of devices.
+
+CCC commands contain an 8-bit CCC id describing the command that is executed.
+The MSB of this id specifies whether this is a broadcast command (bit7 = 0) or a
+unicast one (bit7 = 1).
+
+The command ID can be followed by a payload. Depending on the command, this
+payload is either sent by the master sending the command (write CCC command),
+or sent by the slave receiving the command (read CCC command). Of course, read
+accesses only apply to unicast commands.
+Note that, when sending a CCC command to a specific device, the device address
+is passed in the first byte of the payload.
+
+The payload length is not explicitly passed on the bus, and should be extracted
+from the CCC id.
+
+Note that vendors can use a dedicated range of CCC ids for their own commands
+(0x61-0x7f and 0xe0-0xef).
+
+I3C Private SDR transfers
+-------------------------
+
+Private SDR (Single Data Rate) transfers should be used for anything that is
+device specific and does not require high transfer speed.
+
+It is the equivalent of I2C transfers but in the I3C world. Each transfer is
+passed the device address (dynamic address assigned during DAA), a payload
+and a direction.
+
+The only difference with I2C is that the transfer is much faster (typical SCL
+frequency is 12.5MHz).
+
+I3C Private HDR commands
+------------------------
+
+HDR commands should be used for anything that is device specific and requires
+high transfer speed.
+
+The first thing attached to an HDR command is the HDR mode. There are currently
+3 different modes defined by the I3C specification (refer to the specification
+for more details):
+
+* HDR-DDR: Double Data Rate mode
+* HDR-TSP: Ternary Symbol Pure. Only usable on busses with no I2C devices
+* HDR-TSL: Ternary Symbol Legacy. Usable on busses with I2C devices
+
+When sending an HDR command, the whole bus has to enter HDR mode, which is done
+using a broadcast CCC command.
+Once the bus has entered a specific HDR mode, the master sends the HDR command.
+An HDR command is made of:
+
+* one 16-bits command word
+* N 16-bits data words
+
+Those words may be wrapped with specific preambles/post-ambles which depend on
+the chosen HDR mode and are detailed here (see the specification for more
+details).
+
+The 16-bits command word is made of:
+
+* bit[15]: direction bit, read is 1 write is 0
+* bit[14:8]: command code. Identifies the command being executed, the amount of
+  data words and their meaning
+* bit[7:1]: I3C address of the device this command is addressed to
+* bit[0]: reserved/parity-bit
+
+Backward compatibility with I2C devices
+=======================================
+
+The I3C protocol has been designed to be backward compatible with I2C devices.
+This backward compatibility allows one to connect a mix of I2C and I3C devices
+on the same bus, though, in order to be really efficient, I2C devices should
+be equipped with 50 ns spike filters.
+
+I2C devices can't be discovered like I3C ones and have to be statically
+declared. In order to let the master know what these devices are capable of
+(both in terms of bus related limitations and functionalities), the software
+has to provide some information, which is done through the LVR (Legacy I2C
+Virtual Register).
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index d17a9876b473..8896d3868ae1 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -30,6 +30,7 @@ available subsections can be seen below.
    pci
    spi
    i2c
+   i3c/index
    hsi
    edac
    scsi
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCH v2 4/7] i3c: Add sysfs ABI spec
  2017-12-14 15:16 [PATCH v2 0/7] Add the I3C subsystem Boris Brezillon
                   ` (2 preceding siblings ...)
  2017-12-14 15:16 ` [PATCH v2 3/7] docs: driver-api: Add I3C documentation Boris Brezillon
@ 2017-12-14 15:16 ` Boris Brezillon
  2017-12-14 15:16 ` [PATCH v2 5/7] dt-bindings: i3c: Document core bindings Boris Brezillon
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 50+ messages in thread
From: Boris Brezillon @ 2017-12-14 15:16 UTC (permalink / raw)
  To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij,
	Boris Brezillon

Document sysfs files/directories/symlinks exposed by the I3C subsystem.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Changes in v2:
- new patch
---
 Documentation/ABI/testing/sysfs-bus-i3c | 95 +++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c

diff --git a/Documentation/ABI/testing/sysfs-bus-i3c b/Documentation/ABI/testing/sysfs-bus-i3c
new file mode 100644
index 000000000000..5e88cc093e0e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-i3c
@@ -0,0 +1,95 @@
+What:		/sys/bus/i3c/devices/i3c-<bus-id>
+KernelVersion:  4.16
+Contact:	linux-i3c@vger.kernel.org
+Description:
+		An I3C bus. This directory will contain one sub-directory per
+		I3C device present on the bus.
+
+What:		/sys/bus/i3c/devices/i3c-<bus-id>/current_master
+KernelVersion:  4.16
+Contact:	linux-i3c@vger.kernel.org
+Description:
+		Expose the master that owns the bus (<bus-id>-<master-pid>) at
+		the time this file is read. Note that bus ownership can change
+		overtime, so there's no guarantee that when the read() call
+		returns, the value returned is still valid.
+
+What:		/sys/bus/i3c/devices/i3c-<bus-id>/mode
+KernelVersion:  4.16
+Contact:	linux-i3c@vger.kernel.org
+Description:
+		I3C bus mode. Can be "pure", "mixed-fast" or "mixed-slow". See
+		the I3C specification for a detailed description of what each
+		of these modes implies.
+
+What:		/sys/bus/i3c/devices/i3c-<bus-id>/i3c_scl_frequency
+KernelVersion:  4.16
+Contact:	linux-i3c@vger.kernel.org
+Description:
+		The frequency (expressed in Hz) of the SCL signal when
+		operating in I3C SDR mode.
+
+What:		/sys/bus/i3c/devices/i3c-<bus-id>/i2c_scl_frequency
+KernelVersion:  4.16
+Contact:	linux-i3c@vger.kernel.org
+Description:
+		The frequency (expressed in Hz) of the SCL signal when
+		operating in I2C mode.
+
+What:		/sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>
+KernelVersion:  4.16
+Contact:	linux-i3c@vger.kernel.org
+Description:
+		An I3C device present on I3C bus identified by <bus-id>. Note
+		that all devices are represented including the master driving
+		the bus.
+
+What:		/sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/address
+KernelVersion:  4.16
+Contact:	linux-i3c@vger.kernel.org
+Description:
+		Dynamic address assigned to device <bus-id>-<device-pid>. This
+		address may change if the bus is re-initialized.
+
+What:		/sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/bcr
+KernelVersion:  4.16
+Contact:	linux-i3c@vger.kernel.org
+Description:
+		BCR stands for Bus Characteristics Register and express the
+		device capabilities in term of speed, maximum read/write
+		length, etc. See the I3C specification for more details.
+
+What:		/sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/dcr
+KernelVersion:  4.16
+Contact:	linux-i3c@vger.kernel.org
+Description:
+		DCR stands for Device Characteristics Register and express the
+		device capabilities in term of exposed features. See the I3C
+		specification for more details.
+
+What:		/sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/pid
+KernelVersion:  4.16
+Contact:	linux-i3c@vger.kernel.org
+Description:
+		PID stands for Provisional ID and is used to uniquely identify
+		a device on a bus. This PID contains information about the
+		vendor, the part and an instance ID so that several devices of
+		the same type can be connected on the same bus.
+		See the I3C specification for more details.
+
+What:		/sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/hdrcap
+KernelVersion:  4.16
+Contact:	linux-i3c@vger.kernel.org
+Description:
+		Expose the HDR (High Data Rate) capabilities of a device.
+		Returns a list of supported HDR mode, each element is separated
+		by space. Modes can be "hdr-ddr", "hdr-tsp" and "hdr-tsl".
+		See the I3C specification for more details about these HDR
+		modes.
+
+What:		/sys/bus/i3c/devices/<bus-id>-<device-pid>
+KernelVersion:  4.16
+Contact:	linux-i3c@vger.kernel.org
+Description:
+		These directories are just symbolic links to
+		/sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>.
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
  2017-12-14 15:16 [PATCH v2 0/7] Add the I3C subsystem Boris Brezillon
                   ` (3 preceding siblings ...)
  2017-12-14 15:16 ` [PATCH v2 4/7] i3c: Add sysfs ABI spec Boris Brezillon
@ 2017-12-14 15:16 ` Boris Brezillon
  2017-12-14 16:24   ` Geert Uytterhoeven
                     ` (2 more replies)
  2017-12-14 15:16 ` [PATCH v2 6/7] i3c: master: Add driver for Cadence IP Boris Brezillon
                   ` (2 subsequent siblings)
  7 siblings, 3 replies; 50+ messages in thread
From: Boris Brezillon @ 2017-12-14 15:16 UTC (permalink / raw)
  To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij,
	Boris Brezillon

A new I3C subsystem has been added and a generic description has been
created to represent the I3C bus and the devices connected on it.

Document this generic representation.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Changes in v2:
- Define how to describe I3C devices in the DT and when it should be
  used. Note that the parsing of I3C devices is not yet implemented in
  the framework. Will be added when someone really needs it.
---
 Documentation/devicetree/bindings/i3c/i3c.txt | 128 ++++++++++++++++++++++++++
 1 file changed, 128 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt

diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt b/Documentation/devicetree/bindings/i3c/i3c.txt
new file mode 100644
index 000000000000..79a214dee025
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/i3c.txt
@@ -0,0 +1,128 @@
+Generic device tree bindings for I3C busses
+===========================================
+
+This document describes generic bindings that should be used to describe I3C
+busses in a device tree.
+
+Required properties
+-------------------
+
+- #address-cells  - should be <1>. Read more about addresses below.
+- #size-cells     - should be <0>.
+- compatible      - name of I3C bus controller following generic names
+		    recommended practice.
+
+For other required properties e.g. to describe register sets,
+clocks, etc. check the binding documentation of the specific driver.
+
+Optional properties
+-------------------
+
+These properties may not be supported by all I3C master drivers. Each I3C
+master bindings should specify which of them are supported.
+
+- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
+		     transfers. When undefined the core set it to 12.5MHz.
+
+- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
+		     transfers. When undefined, the core looks at LVR values
+		     of I2C devices described in the device tree to determine
+		     the maximum I2C frequency.
+
+I2C devices
+===========
+
+Each I2C device connected to the bus should be described in a subnode with
+the following properties:
+
+All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
+valid here.
+
+New required properties:
+------------------------
+- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
+	   describing device capabilities as described in the I3C
+	   specification.
+
+	   bit[31:8]: unused
+	   bit[7:5]: I2C device index. Possible values
+	    * 0: I2C device has a 50 ns spike filter
+	    * 1: I2C device does not have a 50 ns spike filter but supports high
+		 frequency on SCL
+	    * 2: I2C device does not have a 50 ns spike filter and is not
+		 tolerant to high frequencies
+	    * 3-7: reserved
+
+	   bit[4]: tell whether the device operates in FM or FM+ mode
+	    * 0: FM+ mode
+	    * 1: FM mode
+
+	   bit[3:0]: device type
+	    * 0-15: reserved
+
+I3C devices
+===========
+
+All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
+are thus discoverable. So, by default, I3C devices do not have to be described
+in the device tree.
+This being said, one might want to attach extra resources to these devices,
+and those resources may have to be described in the device tree, which in turn
+means we have to describe I3C devices.
+
+Another use case for describing an I3C device in the device tree is when this
+I3C device has a static address and we want to assign it a specific dynamic
+address before the DAA takes place (so that other devices on the bus can't
+take this dynamic address).
+
+Required properties
+-------------------
+- i3c-pid: PID (Provisional ID). 64-bit property which is used to match a
+	   device discovered during DAA with its device tree definition. The
+	   PID is supposed to be unique on a given bus, which guarantees a 1:1
+	   match. This property becomes optional if a reg property is defined,
+	   meaning that the device has a static address.
+
+Optional properties
+-------------------
+- reg: static address. Only valid is the device has a static address.
+- i3c-dynamic-address: dynamic address to be assigned to this device. This
+		       property depends on the reg property.
+
+Example:
+
+	i3c-master@0d040000 {
+		compatible = "cdns,i3c-master";
+		clocks = <&coreclock>, <&i3csysclock>;
+		clock-names = "pclk", "sysclk";
+		interrupts = <3 0>;
+		reg = <0x0d040000 0x1000>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		status = "okay";
+		i2c-scl-frequency = <100000>;
+
+		/* I2C device. */
+		nunchuk: nunchuk@52 {
+			compatible = "nintendo,nunchuk";
+			reg = <0x52>;
+			i3c-lvr = <0x10>;
+		};
+
+		/* I3C device with a static address. */
+		thermal_sensor: sensor@68 {
+			reg = <0x68>;
+			i3c-dynamic-address = <0xa>;
+		};
+
+		/*
+		 * I3C device without a static address but requiring resources
+		 * described in the DT.
+		 */
+		sensor2 {
+			i3c-pid = /bits/ 64 <0x39200144004>;
+			clocks = <&clock_provider 0>;
+		};
+	};
+
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCH v2 6/7] i3c: master: Add driver for Cadence IP
  2017-12-14 15:16 [PATCH v2 0/7] Add the I3C subsystem Boris Brezillon
                   ` (4 preceding siblings ...)
  2017-12-14 15:16 ` [PATCH v2 5/7] dt-bindings: i3c: Document core bindings Boris Brezillon
@ 2017-12-14 15:16 ` Boris Brezillon
  2017-12-14 19:54   ` Randy Dunlap
  2017-12-14 15:16 ` [PATCH v2 7/7] dt-bindings: i3c: Document Cadence I3C master bindings Boris Brezillon
  2018-02-22 15:00 ` [PATCH v2 0/7] Add the I3C subsystem Vitor Soares
  7 siblings, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2017-12-14 15:16 UTC (permalink / raw)
  To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij,
	Boris Brezillon

Add a driver for Cadence I3C master IP.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Changes in v2:
- Add basic IBI support. Note that the IP is not really reliable with
  regards to IBI because you can't extract IBI payloads as soon as you
  have more than one IBI waiting in the HW queue. This is something
  that will hopefully be addressed in future revisions of this IP
- Add a simple xfer queueing mechanism to optimize message queuing.
- Fix a few bugs
- Add support for Hot Join
---
 drivers/i3c/master/Kconfig           |    5 +
 drivers/i3c/master/Makefile          |    1 +
 drivers/i3c/master/i3c-master-cdns.c | 1797 ++++++++++++++++++++++++++++++++++
 3 files changed, 1803 insertions(+)
 create mode 100644 drivers/i3c/master/i3c-master-cdns.c

diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
index e69de29bb2d1..56b9a18543b2 100644
--- a/drivers/i3c/master/Kconfig
+++ b/drivers/i3c/master/Kconfig
@@ -0,0 +1,5 @@
+config CDNS_I3C_MASTER
+	tristate "Cadence I3C master driver"
+	depends on I3C
+	help
+	  Enable this driver if you want to support Cadence I3C master block.
diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
index e69de29bb2d1..4c4304aa9534 100644
--- a/drivers/i3c/master/Makefile
+++ b/drivers/i3c/master/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CDNS_I3C_MASTER)		+= i3c-master-cdns.o
diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c
new file mode 100644
index 000000000000..3e3ef37c01c2
--- /dev/null
+++ b/drivers/i3c/master/i3c-master-cdns.c
@@ -0,0 +1,1797 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/i3c/master.h>
+#include <linux/interrupt.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#define DEV_ID				0x0
+#define DEV_ID_I3C_MASTER		0x5034
+
+#define CONF_STATUS0			0x4
+#define CONF_STATUS0_ECC_CHK		BIT(28)
+#define CONF_STATUS0_INTEG_CHK		BIT(27)
+#define CONF_STATUS0_CSR_DAP_CHK	BIT(26)
+#define CONF_STATUS0_TRANS_TOUT_CHK	BIT(25)
+#define CONF_STATUS0_PROT_FAULTS_CHK	BIT(24)
+#define CONF_STATUS0_GPO_NUM(x)		(((x) & GENMASK(23, 16)) >> 16)
+#define CONF_STATUS0_GPI_NUM(x)		(((x) & GENMASK(15, 8)) >> 8)
+#define CONF_STATUS0_SUPPORTS_DDR	BIT(5)
+#define CONF_STATUS0_SEC_MASTER		BIT(4)
+#define CONF_STATUS0_DEVS_NUM(x)	((x) & GENMASK(3, 0))
+
+#define CONF_STATUS1			0x8
+#define CONF_STATUS1_IBI_HW_RES(x)	((((x) & GENMASK(31, 28)) >> 28) + 1)
+#define CONF_STATUS1_CMD_DEPTH(x)	(4 << (((x) & GENMASK(27, 26)) >> 26))
+#define CONF_STATUS1_SLVDDR_RX_DEPTH(x)	(8 << (((x) & GENMASK(25, 21)) >> 21))
+#define CONF_STATUS1_SLVDDR_TX_DEPTH(x)	(8 << (((x) & GENMASK(20, 16)) >> 16))
+#define CONF_STATUS1_IBI_DEPTH(x)	(2 << (((x) & GENMASK(12, 10)) >> 10))
+#define CONF_STATUS1_RX_DEPTH(x)	(8 << (((x) & GENMASK(9, 5)) >> 5))
+#define CONF_STATUS1_TX_DEPTH(x)	(8 << ((x) & GENMASK(4, 0)))
+
+#define REV_ID				0xc
+#define REV_ID_VID(id)			(((id) & GENMASK(31, 20)) >> 20)
+#define REV_ID_PID(id)			(((id) & GENMASK(19, 8)) >> 8)
+#define REV_ID_REV_MAJOR(id)		(((id) & GENMASK(7, 4)) >> 4)
+#define REV_ID_REV_MINOR(id)		((id) & GENMASK(3, 0))
+
+#define CTRL				0x10
+#define CTRL_DEV_EN			BIT(31)
+#define CTRL_HALT_EN			BIT(30)
+#define CTRL_HJ_DISEC			BIT(8)
+#define CTRL_MST_ACK			BIT(7)
+#define CTRL_HJ_ACK			BIT(6)
+#define CTRL_HJ_INIT			BIT(5)
+#define CTRL_MST_INIT			BIT(4)
+#define CTRL_AHDR_OPT			BIT(3)
+#define CTRL_PURE_BUS_MODE		0
+#define CTRL_MIXED_FAST_BUS_MODE	2
+#define CTRL_MIXED_SLOW_BUS_MODE	3
+#define CTRL_BUS_MODE_MASK		GENMASK(1, 0)
+
+#define PRESCL_CTRL0			0x14
+#define PRESCL_CTRL0_I2C(x)		((x) << 16)
+#define PRESCL_CTRL0_I3C(x)		(x)
+#define PRESCL_CTRL0_MAX		GENMASK(9, 0)
+
+#define PRESCL_CTRL1			0x18
+#define PRESCL_CTRL1_PP_LOW_MASK	GENMASK(15, 8)
+#define PRESCL_CTRL1_PP_LOW(x)		((x) << 8)
+#define PRESCL_CTRL1_OD_LOW_MASK	GENMASK(7, 0)
+#define PRESCL_CTRL1_OD_LOW(x)		(x)
+
+#define MST_IER				0x20
+#define MST_IDR				0x24
+#define MST_IMR				0x28
+#define MST_ICR				0x2c
+#define MST_ISR				0x30
+#define MST_INT_M0_ERR			BIT(28)
+#define MST_INT_RX_THR			BIT(24)
+#define MST_INT_TX_THR			BIT(23)
+#define MST_INT_IBI_THR			BIT(22)
+#define MST_INT_CMD_THR			BIT(21)
+#define MST_INT_RX_UNF			BIT(20)
+#define MST_INT_TX_OVF			BIT(19)
+#define MST_INT_IBI_UNF			BIT(18)
+#define MST_INT_CMD_OVF			BIT(17)
+#define MST_INT_CMD_EMPTY		BIT(16)
+#define MST_INT_MR_DONE			BIT(11)
+#define MST_INT_IBI_FAIL		BIT(10)
+#define MST_INT_SDR_FAIL		BIT(9)
+#define MST_INT_DDR_FAIL		BIT(8)
+#define MST_INT_HJ_REQ			BIT(7)
+#define MST_INT_MR_REQ			BIT(6)
+#define MST_INT_IBI_REQ			BIT(5)
+#define MST_INT_BUS_DISCR		BIT(4)
+#define MST_INT_INVALID_DA		BIT(3)
+#define MST_INT_RD_ABORT		BIT(2)
+#define MST_INT_NACK			BIT(1)
+#define MST_INT_COMP			BIT(0)
+
+#define MST_INT_XFER_STATUS		(MST_INT_M0_ERR |	\
+					 MST_INT_SDR_FAIL |	\
+					 MST_INT_DDR_FAIL |	\
+					 MST_INT_INVALID_DA |	\
+					 MST_INT_RD_ABORT |	\
+					 MST_INT_NACK |		\
+					 MST_INT_COMP)
+
+#define MST_STATUS0			0x34
+#define MST_STATUS0_IDLE		BIT(31)
+#define MST_STATUS0_HALTED		BIT(30)
+#define MST_STATUS0_MASTER_MODE		BIT(29)
+#define MST_STATUS0_IMM_COMP		BIT(28)
+#define MST_STATUS0_DDR_ERR_ID(s)	((s) & GENMASK(27, 25) >> 25)
+#define MST_STATUS0_DAA_COMP		BIT(24)
+#define MST_STATUS0_IBI_FIFO_FULL	BIT(23)
+#define MST_STATUS0_RX_FIFO_FULL	BIT(22)
+#define MST_STATUS0_XFER_BYTES(s)	((s) & GENMASK(21, 10) >> 10)
+#define MST_STATUS0_DEV_ADDR(s)		((s) & GENMASK(9, 0))
+
+#define SIR_STATUS			0x3c
+#define SIR_STATUS_DEV(d)		BIT(d)
+
+#define SLV_IER				0x40
+#define SLV_IDR				0x44
+#define SLV_IMR				0x48
+#define SLV_ICR				0x4c
+#define SLV_ISR				0x50
+#define SLV_INT_TM			BIT(20)
+#define SLV_INT_ERROR			BIT(19)
+#define SLV_INT_EVENT_UP		BIT(18)
+#define SLV_INT_HJ_DONE			BIT(17)
+#define SLV_INT_MR_DONE			BIT(16)
+#define SLV_INT_SDR_FAIL		BIT(14)
+#define SLV_INT_DDR_FAIL		BIT(13)
+#define SLV_INT_M_RD_ABORT		BIT(12)
+#define SLV_INT_DDR_RX_THR		BIT(11)
+#define SLV_INT_DDR_TX_THR		BIT(10)
+#define SLV_INT_SDR_RX_THR		BIT(9)
+#define SLV_INT_SDR_TX_THR		BIT(8)
+#define SLV_INT_DDR_RX_UNF		BIT(7)
+#define SLV_INT_DDR_TX_OVF		BIT(6)
+#define SLV_INT_SDR_RX_UNF		BIT(5)
+#define SLV_INT_SDR_TX_OVF		BIT(4)
+#define SLV_INT_DDR_RD_COMP		BIT(3)
+#define SLV_INT_DDR_WR_COMP		BIT(2)
+#define SLV_INT_SDR_RD_COMP		BIT(1)
+#define SLV_INT_SDR_WR_COMP		BIT(0)
+
+#define SLV_STATUS0			0x54
+#define SLV_STATUS0_REG_ADDR(s)		(((s) & GENMASK(23, 16)) >> 16)
+#define SLV_STATUS0_XFRD_BYTES(s)	((s) & GENMASK(15, 0))
+
+#define SLV_STATUS1			0x58
+#define SLV_STATUS1_AS(s)		(((s) & GENMASK(21, 20)) >> 20)
+#define SLV_STATUS1_VEN_TM		BIT(19)
+#define SLV_STATUS1_HJ_DIS		BIT(18)
+#define SLV_STATUS1_MR_DIS		BIT(17)
+#define SLV_STATUS1_PROT_ERR		BIT(16)
+#define SLV_STATUS1_DDR_RX_FULL		BIT(7)
+#define SLV_STATUS1_DDR_TX_FULL		BIT(6)
+#define SLV_STATUS1_DDR_RX_EMPTY	BIT(5)
+#define SLV_STATUS1_DDR_TX_EMPTY	BIT(4)
+#define SLV_STATUS1_SDR_RX_FULL		BIT(3)
+#define SLV_STATUS1_SDR_TX_FULL		BIT(2)
+#define SLV_STATUS1_SDR_RX_EMPTY	BIT(1)
+#define SLV_STATUS1_SDR_TX_EMPTY	BIT(0)
+
+#define CMD0_FIFO			0x60
+#define CMD0_FIFO_IS_DDR		BIT(31)
+#define CMD0_FIFO_IS_CCC		BIT(30)
+#define CMD0_FIFO_BCH			BIT(29)
+#define XMIT_BURST_STATIC_SUBADDR	0
+#define XMIT_SINGLE_INC_SUBADDR		1
+#define XMIT_SINGLE_STATIC_SUBADDR	2
+#define XMIT_BURST_WITHOUT_SUBADDR	3
+#define CMD0_FIFO_PRIV_XMIT_MODE(m)	((m) << 27)
+#define CMD0_FIFO_SBCA			BIT(26)
+#define CMD0_FIFO_RSBC			BIT(25)
+#define CMD0_FIFO_IS_10B		BIT(24)
+#define CMD0_FIFO_PL_LEN(l)		((l) << 12)
+#define CMD0_FIFO_PL_LEN_MAX		4095
+#define CMD0_FIFO_DEV_ADDR(a)		((a) << 1)
+#define CMD0_FIFO_RNW			BIT(0)
+
+#define CMD1_FIFO			0x64
+#define CMD1_FIFO_CSRADDR(a)		(a)
+#define CMD1_FIFO_CCC(id)		(id)
+
+#define TX_FIFO				0x68
+
+#define IMD_CMD0			0x70
+#define IMD_CMD0_PL_LEN(l)		((l) << 12)
+#define IMD_CMD0_DEV_ADDR(a)		((a) << 1)
+#define IMD_CMD0_RNW			BIT(0)
+
+#define IMD_CMD1			0x74
+#define IMD_CMD1_CCC(id)		(id)
+
+#define IMD_DATA			0x78
+#define RX_FIFO				0x80
+#define IBI_DATA_FIFO			0x84
+#define SLV_DDR_TX_FIFO			0x88
+#define SLV_DDR_RX_FIFO			0x8c
+
+#define CMD_IBI_THR_CTRL		0x90
+#define IBI_THR(t)			((t) << 8)
+#define CMD_THR(t)			(t)
+
+#define TX_RX_THR_CTRL			0x94
+#define RX_THR(t)			((t) << 16)
+#define TX_THR(t)			(t)
+
+#define SLV_DDR_TX_RX_THR_CTRL		0x98
+#define SLV_DDR_RX_THR(t)		((t) << 16)
+#define SLV_DDR_TX_THR(t)		(t)
+
+#define FLUSH_CTRL			0x9c
+#define FLUSH_SLV_DDR_RX_FIFO		BIT(22)
+#define FLUSH_SLV_DDR_TX_FIFO		BIT(21)
+#define FLUSH_IMM_FIFO			BIT(20)
+#define FLUSH_IBI_FIFO			BIT(19)
+#define FLUSH_RX_FIFO			BIT(18)
+#define FLUSH_TX_FIFO			BIT(17)
+#define FLUSH_CMD_FIFO			BIT(16)
+
+#define TTO_PRESCL_CTRL0		0xb0
+#define TTO_PRESCL_CTRL0_DIVB(x)	((x) << 16)
+#define TTO_PRESCL_CTRL0_DIVA(x)	(x)
+
+#define TTO_PRESCL_CTRL1		0xb4
+#define TTO_PRESCL_CTRL1_DIVB(x)	((x) << 16)
+#define TTO_PRESCL_CTRL1_DIVA(x)	(x)
+
+#define DEVS_CTRL			0xb8
+#define DEVS_CTRL_DEV_CLR_ALL		GENMASK(31, 16)
+#define DEVS_CTRL_DEV_CLR(dev)		BIT(16 + (dev))
+#define DEVS_CTRL_DEV_ACTIVE(dev)	BIT(dev)
+
+#define DEV_ID_RR0(d)			(0xc0 + ((d) * 0x10))
+#define DEV_ID_RR0_LVR_EXT_ADDR		BIT(11)
+#define DEV_ID_RR0_HDR_CAP		BIT(10)
+#define DEV_ID_RR0_IS_I3C		BIT(9)
+#define DEV_ID_RR0_SET_DEV_ADDR(a)	(((a) & GENMASK(6, 0)) |	\
+					 (((a) & GENMASK(9, 7)) << 6))
+#define DEV_ID_RR0_GET_DEV_ADDR(x)	((((x) >> 1) & GENMASK(6, 0)) |	\
+					 (((x) >> 6) & GENMASK(9, 7)))
+
+#define DEV_ID_RR1(d)			(0xc4 + ((d) * 0x10))
+#define DEV_ID_RR1_PID_MSB(pid)		(pid)
+
+#define DEV_ID_RR2(d)			(0xc8 + ((d) * 0x10))
+#define DEV_ID_RR2_PID_LSB(pid)		((pid) << 16)
+#define DEV_ID_RR2_BCR(bcr)		((bcr) << 8)
+#define DEV_ID_RR2_DCR(dcr)		(dcr)
+#define DEV_ID_RR2_LVR(lvr)		(lvr)
+
+#define SIR_MAP(x)			(0x180 + ((x) * 4))
+#define SIR_MAP_DEV_REG(d)		SIR_MAP((d) / 2)
+#define SIR_MAP_DEV_SHIFT(d, fs)	((fs) + (((d) % 2) ? 16 : 0))
+#define SIR_MAP_DEV_CONF_MASK(d)	(GENMASK(15, 0) << (((d) % 2) ? 16 : 0))
+#define SIR_MAP_DEV_CONF(d, c)		((c) << (((d) % 2) ? 16 : 0))
+#define DEV_ROLE_SLAVE			0
+#define DEV_ROLE_MASTER			1
+#define SIR_MAP_DEV_ROLE(role)		((role) << 14)
+#define SIR_MAP_DEV_SLOW		BIT(13)
+#define SIR_MAP_DEV_PL(l)		((l) << 8)
+#define SIR_MAP_PL_MAX			GENMASK(4, 0)
+#define SIR_MAP_DEV_DA(a)		((a) << 1)
+#define SIR_MAP_DEV_ACK			BIT(0)
+
+#define GPIR_WORD(x)			(0x200 + ((x) * 4))
+#define GPI_REG(val, id)		\
+	(((val) >> (((id) % 4) * 8)) & GENMASK(7, 0))
+
+#define GPOR_WORD(x)			(0x220 + ((x) * 4))
+#define GPO_REG(val, id)		\
+	(((val) >> (((id) % 4) * 8)) & GENMASK(7, 0))
+
+#define ASF_INT_STATUS			0x300
+#define ASF_INT_RAW_STATUS		0x304
+#define ASF_INT_MASK			0x308
+#define ASF_INT_TEST			0x30c
+#define ASF_INT_FATAL_SELECT		0x310
+#define ASF_INTEGRITY_ERR		BIT(6)
+#define ASF_PROTOCOL_ERR		BIT(5)
+#define ASF_TRANS_TIMEOUT_ERR		BIT(4)
+#define ASF_CSR_ERR			BIT(3)
+#define ASF_DAP_ERR			BIT(2)
+#define ASF_SRAM_UNCORR_ERR		BIT(1)
+#define ASF_SRAM_CORR_ERR		BIT(0)
+
+#define ASF_SRAM_CORR_FAULT_STATUS	0x320
+#define ASF_SRAM_UNCORR_FAULT_STATUS	0x324
+#define ASF_SRAM_CORR_FAULT_INSTANCE(x)	((x) >> 24)
+#define ASF_SRAM_CORR_FAULT_ADDR(x)	((x) & GENMASK(23, 0))
+
+#define ASF_SRAM_FAULT_STATS		0x328
+#define ASF_SRAM_FAULT_UNCORR_STATS(x)	((x) >> 16)
+#define ASF_SRAM_FAULT_CORR_STATS(x)	((x) & GENMASK(15, 0))
+
+#define ASF_TRANS_TOUT_CTRL		0x330
+#define ASF_TRANS_TOUT_EN		BIT(31)
+#define ASF_TRANS_TOUT_VAL(x)	(x)
+
+#define ASF_TRANS_TOUT_FAULT_MASK	0x334
+#define ASF_TRANS_TOUT_FAULT_STATUS	0x338
+#define ASF_TRANS_TOUT_FAULT_APB	BIT(3)
+#define ASF_TRANS_TOUT_FAULT_SCL_LOW	BIT(2)
+#define ASF_TRANS_TOUT_FAULT_SCL_HIGH	BIT(1)
+#define ASF_TRANS_TOUT_FAULT_FSCL_HIGH	BIT(0)
+
+#define ASF_PROTO_FAULT_MASK		0x340
+#define ASF_PROTO_FAULT_STATUS		0x344
+#define ASF_PROTO_FAULT_SLVSDR_RD_ABORT	BIT(31)
+#define ASF_PROTO_FAULT_SLVDDR_FAIL	BIT(30)
+#define ASF_PROTO_FAULT_S(x)		BIT(16 + (x))
+#define ASF_PROTO_FAULT_MSTSDR_RD_ABORT	BIT(15)
+#define ASF_PROTO_FAULT_MSTDDR_FAIL	BIT(14)
+#define ASF_PROTO_FAULT_M(x)		BIT(x)
+
+struct cdns_i3c_master_caps {
+	u32 cmdfifodepth;
+	u32 txfifodepth;
+	u32 rxfifodepth;
+};
+
+struct cdns_i3c_cmd {
+	u32 cmd0;
+	u32 cmd1;
+	u32 tx_len;
+	const void *tx_buf;
+	u32 rx_len;
+	void *rx_buf;
+};
+
+struct cdns_i3c_xfer {
+	struct list_head node;
+	struct completion comp;
+	u32 isr;
+	unsigned int ncmds;
+	struct cdns_i3c_cmd cmds[0];
+};
+
+struct cdns_i3c_master {
+	struct work_struct hj_work;
+	struct i3c_master_controller base;
+	unsigned long free_dev_slots;
+	struct {
+		unsigned int num_slots;
+		struct i3c_device **slots;
+		spinlock_t lock;
+	} ibi;
+	struct {
+		struct list_head list;
+		struct cdns_i3c_xfer *cur;
+		spinlock_t lock;
+	} xferqueue;
+	void __iomem *regs;
+	struct clk *sysclk;
+	struct clk *pclk;
+	struct cdns_i3c_master_caps caps;
+	unsigned long i3c_scl_lim;
+};
+
+static inline struct cdns_i3c_master *
+to_cdns_i3c_master(struct i3c_master_controller *master)
+{
+	return container_of(master, struct cdns_i3c_master, base);
+}
+
+static void cdns_i3c_master_wr_to_tx_fifo(struct cdns_i3c_master *master,
+					  const u8 *bytes, int nbytes)
+{
+	int i, j;
+
+	for (i = 0; i < nbytes; i += 4) {
+		u32 data = 0;
+
+		for (j = 0; j < 4 && (i + j) < nbytes; j++)
+			data |= (u32)bytes[i + j] << (j * 8);
+
+		writel(data, master->regs + TX_FIFO);
+	}
+}
+
+static void cdns_i3c_master_drain_rx_fifo(struct cdns_i3c_master *master)
+{
+	int i;
+
+	for (i = 0; i < master->caps.rxfifodepth; i++) {
+		readl(master->regs + RX_FIFO);
+		if (readl(master->regs + MST_ISR) & MST_INT_RX_UNF) {
+			writel(MST_INT_RX_UNF, master->regs + MST_ICR);
+			break;
+		}
+	}
+}
+
+static void cdns_i3c_master_rd_from_rx_fifo(struct cdns_i3c_master *master,
+					    u8 *bytes, int nbytes)
+{
+	u32 status0;
+	int i, j;
+
+	status0 = readl(master->regs + MST_STATUS0);
+
+	if (nbytes > MST_STATUS0_XFER_BYTES(status0))
+		nbytes = MST_STATUS0_XFER_BYTES(status0);
+
+	for (i = 0; i < nbytes; i += 4) {
+		u32 data;
+
+		data = readl(master->regs + RX_FIFO);
+
+		for (j = 0; j < 4 && (i + j) < nbytes; j++)
+			bytes[i + j] = data >> (j * 8);
+	}
+}
+
+static bool cdns_i3c_master_supports_ccc_cmd(struct i3c_master_controller *m,
+					     const struct i3c_ccc_cmd *cmd)
+{
+	if (cmd->ndests > 1)
+		return false;
+
+	switch (cmd->id) {
+	case I3C_CCC_ENEC(true):
+	case I3C_CCC_ENEC(false):
+	case I3C_CCC_DISEC(true):
+	case I3C_CCC_DISEC(false):
+	case I3C_CCC_ENTAS(0, true):
+	case I3C_CCC_ENTAS(0, false):
+	case I3C_CCC_RSTDAA(true):
+	case I3C_CCC_RSTDAA(false):
+	case I3C_CCC_ENTDAA:
+	case I3C_CCC_SETMWL(true):
+	case I3C_CCC_SETMWL(false):
+	case I3C_CCC_SETMRL(true):
+	case I3C_CCC_SETMRL(false):
+	case I3C_CCC_DEFSLVS:
+	case I3C_CCC_ENTHDR(0):
+	case I3C_CCC_SETDASA:
+	case I3C_CCC_SETNEWDA:
+	case I3C_CCC_GETMWL:
+	case I3C_CCC_GETMRL:
+	case I3C_CCC_GETPID:
+	case I3C_CCC_GETBCR:
+	case I3C_CCC_GETDCR:
+	case I3C_CCC_GETSTATUS:
+	case I3C_CCC_GETACCMST:
+	case I3C_CCC_GETMXDS:
+	case I3C_CCC_GETHDRCAP:
+		return true;
+	default:
+		break;
+	}
+
+	return false;
+}
+
+static int cdns_i3c_master_disable(struct cdns_i3c_master *master)
+{
+	u32 status;
+
+	writel(readl(master->regs + CTRL) & ~CTRL_DEV_EN, master->regs + CTRL);
+
+	return readl_poll_timeout(master->regs + MST_STATUS0, status,
+				  status & MST_STATUS0_IDLE, 10, 1000000);
+}
+
+static void cdns_i3c_master_enable(struct cdns_i3c_master *master)
+{
+	writel(readl(master->regs + CTRL) | CTRL_DEV_EN, master->regs + CTRL);
+}
+
+static struct cdns_i3c_xfer *
+cdns_i3c_master_alloc_xfer(struct cdns_i3c_master *master, unsigned int ncmds)
+{
+	struct cdns_i3c_xfer *xfer;
+
+	xfer = kzalloc(sizeof(*xfer) + (ncmds * sizeof(*xfer->cmds)),
+		       GFP_KERNEL);
+	if (!xfer)
+		return NULL;
+
+	INIT_LIST_HEAD(&xfer->node);
+	xfer->ncmds = ncmds;
+
+	return xfer;
+}
+
+static void cdns_i3c_master_free_xfer(struct cdns_i3c_xfer *xfer)
+{
+	kfree(xfer);
+}
+
+static void cdns_i3c_master_start_xfer_locked(struct cdns_i3c_master *master)
+{
+	struct cdns_i3c_xfer *xfer = master->xferqueue.cur;
+	unsigned int i;
+
+	if (!xfer)
+		return;
+
+	writel(MST_INT_XFER_STATUS | MST_INT_CMD_EMPTY,
+	       master->regs + MST_ICR);
+	for (i = 0; i < xfer->ncmds; i++) {
+		struct cdns_i3c_cmd *cmd = &xfer->cmds[i];
+
+		cdns_i3c_master_wr_to_tx_fifo(master, cmd->tx_buf,
+					      cmd->tx_len);
+	}
+
+	for (i = 0; i < xfer->ncmds; i++) {
+		struct cdns_i3c_cmd *cmd = &xfer->cmds[i];
+
+		writel(cmd->cmd1, master->regs + CMD1_FIFO);
+		writel(cmd->cmd0, master->regs + CMD0_FIFO);
+	}
+
+	writel(MST_INT_CMD_EMPTY | MST_INT_RD_ABORT, master->regs + MST_IER);
+}
+
+static void cdns_i3c_master_end_xfer_locked(struct cdns_i3c_master *master,
+					    u32 isr)
+{
+	struct cdns_i3c_xfer *xfer = master->xferqueue.cur;
+
+	if (!xfer)
+		return;
+
+	isr &= MST_INT_XFER_STATUS | MST_INT_CMD_EMPTY;
+	if (!isr)
+		return;
+
+	writel(MST_INT_CMD_EMPTY | MST_INT_RD_ABORT, master->regs + MST_IDR);
+	xfer->isr = isr & ~MST_INT_CMD_EMPTY;
+
+	if (xfer->isr & MST_INT_RD_ABORT) {
+		writel(FLUSH_RX_FIFO | FLUSH_TX_FIFO | FLUSH_CMD_FIFO,
+		       master->regs + FLUSH_CTRL);
+		writel(readl(master->regs + CTRL) | CTRL_DEV_EN,
+		       master->regs + CTRL);
+	} else if (xfer->isr != MST_INT_COMP) {
+		cdns_i3c_master_drain_rx_fifo(master);
+	} else {
+		unsigned int i;
+
+		for (i = 0; i < xfer->ncmds; i++) {
+			struct cdns_i3c_cmd *cmd = &xfer->cmds[i];
+
+			cdns_i3c_master_rd_from_rx_fifo(master, cmd->rx_buf,
+							cmd->rx_len);
+		}
+	}
+
+	complete(&xfer->comp);
+
+	xfer = list_first_entry_or_null(&master->xferqueue.list,
+					struct cdns_i3c_xfer, node);
+	if (xfer)
+		list_del_init(&xfer->node);
+
+	master->xferqueue.cur = xfer;
+	cdns_i3c_master_start_xfer_locked(master);
+}
+
+static void cdns_i3c_master_queue_xfer(struct cdns_i3c_master *master,
+				       struct cdns_i3c_xfer *xfer)
+{
+	unsigned long flags;
+
+	init_completion(&xfer->comp);
+	spin_lock_irqsave(&master->xferqueue.lock, flags);
+	if (master->xferqueue.cur) {
+		list_add_tail(&xfer->node, &master->xferqueue.list);
+	} else {
+		master->xferqueue.cur = xfer;
+		cdns_i3c_master_start_xfer_locked(master);
+	}
+	spin_unlock_irqrestore(&master->xferqueue.lock, flags);
+}
+
+static void cdns_i3c_master_unqueue_xfer(struct cdns_i3c_master *master,
+					 struct cdns_i3c_xfer *xfer)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&master->xferqueue.lock, flags);
+	if (master->xferqueue.cur == xfer) {
+		u32 status;
+
+		writel(readl(master->regs + CTRL) & ~CTRL_DEV_EN,
+		       master->regs + CTRL);
+		readl_poll_timeout_atomic(master->regs + MST_STATUS0, status,
+					  status & MST_STATUS0_IDLE, 10,
+					  1000000);
+		master->xferqueue.cur = NULL;
+		writel(FLUSH_RX_FIFO | FLUSH_TX_FIFO | FLUSH_CMD_FIFO,
+		       master->regs + FLUSH_CTRL);
+		writel(MST_INT_CMD_EMPTY | MST_INT_RD_ABORT,
+		       master->regs + MST_IDR);
+		writel(readl(master->regs + CTRL) | CTRL_DEV_EN,
+		       master->regs + CTRL);
+	} else {
+		list_del_init(&xfer->node);
+	}
+	spin_unlock_irqrestore(&master->xferqueue.lock, flags);
+}
+
+static int cdns_i3c_master_send_ccc_cmd(struct i3c_master_controller *m,
+					struct i3c_ccc_cmd *cmd)
+{
+	struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+	struct cdns_i3c_xfer *xfer;
+	struct cdns_i3c_cmd *ccmd;
+	int ret;
+
+	xfer = cdns_i3c_master_alloc_xfer(master, 1);
+	if (!xfer)
+		return -ENOMEM;
+
+	ccmd = xfer->cmds;
+	ccmd->cmd1 = CMD1_FIFO_CCC(cmd->id);
+	ccmd->cmd0 = CMD0_FIFO_IS_CCC |
+		     CMD0_FIFO_PL_LEN(cmd->dests[0].payload.len);
+
+	if (cmd->id & I3C_CCC_DIRECT)
+		ccmd->cmd0 |= CMD0_FIFO_DEV_ADDR(cmd->dests[0].addr);
+
+	if (cmd->rnw) {
+		ccmd->cmd0 |= CMD0_FIFO_RNW;
+		ccmd->rx_buf = cmd->dests[0].payload.data;
+		ccmd->rx_len = cmd->dests[0].payload.len;
+	} else {
+		ccmd->tx_buf = cmd->dests[0].payload.data;
+		ccmd->tx_len = cmd->dests[0].payload.len;
+	}
+
+	cdns_i3c_master_queue_xfer(master, xfer);
+	if (!wait_for_completion_timeout(&xfer->comp, msecs_to_jiffies(1000)))
+		cdns_i3c_master_unqueue_xfer(master, xfer);
+
+	/*
+	 * MST_INT_NACK is not an error when doing DAA, it just means "no i3c
+	 * devices on the bus".
+	 */
+	if (xfer->isr == MST_INT_COMP)
+		ret = 0;
+	else if (xfer->isr)
+		ret = -EIO;
+	else
+		ret = -ETIMEDOUT;
+
+	cdns_i3c_master_free_xfer(xfer);
+
+	return ret;
+}
+
+static int cdns_i3c_master_contig_priv_xfers(struct cdns_i3c_master *master,
+					     const struct i3c_priv_xfer *xfers,
+					     int nxfers)
+{
+	struct cdns_i3c_xfer *xfer;
+	unsigned int i;
+	int ret;
+
+	xfer = cdns_i3c_master_alloc_xfer(master, nxfers);
+	if (!xfer)
+		return -ENOMEM;
+
+	for (i = 0; i < nxfers; i++) {
+		struct cdns_i3c_cmd *ccmd = &xfer->cmds[i];
+		u32 pl_len = xfers[i].len;
+
+		ccmd->cmd0 = CMD0_FIFO_DEV_ADDR(xfers[i].addr) |
+			CMD0_FIFO_PRIV_XMIT_MODE(XMIT_BURST_WITHOUT_SUBADDR);
+
+		if (xfers[i].flags & I3C_PRIV_XFER_READ) {
+			ccmd->cmd0 |= CMD0_FIFO_RNW;
+			ccmd->rx_buf = xfers[i].data.in;
+			ccmd->rx_len = xfers[i].len;
+			pl_len++;
+		} else {
+			ccmd->tx_buf = xfers[i].data.out;
+			ccmd->tx_len = xfers[i].len;
+		}
+
+		ccmd->cmd0 |= CMD0_FIFO_PL_LEN(pl_len);
+
+		if (i < nxfers - 1)
+			ccmd->cmd0 |= CMD0_FIFO_RSBC;
+
+		if (!i)
+			ccmd->cmd0 |= CMD0_FIFO_BCH;
+	}
+
+	cdns_i3c_master_queue_xfer(master, xfer);
+	if (!wait_for_completion_timeout(&xfer->comp, msecs_to_jiffies(1000)))
+		cdns_i3c_master_unqueue_xfer(master, xfer);
+
+	if (!xfer->isr)
+		ret = -ETIMEDOUT;
+	else if (xfer->isr &
+		 (MST_INT_NACK | MST_INT_RD_ABORT | MST_INT_INVALID_DA))
+		ret = -EIO;
+	else
+		ret = 0;
+
+	cdns_i3c_master_free_xfer(xfer);
+
+	return ret;
+}
+
+static int cdns_i3c_master_priv_xfers(struct i3c_master_controller *m,
+				      const struct i3c_priv_xfer *xfers,
+				      int nxfers)
+{
+	struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+	int tnxfers = 0, tntx = 0, tnrx = 0, j = 0, i, ret = 0;
+
+	for (i = 0; i < nxfers; i++) {
+		if (xfers[i].len > CMD0_FIFO_PL_LEN_MAX)
+			return -ENOTSUPP;
+	}
+
+	if (!nxfers)
+		return 0;
+
+	/*
+	 * First make sure that all transactions (block of transfers separated
+	 * by a STOP marker) fit in the FIFOs.
+	 */
+	for (i = 0; i < nxfers; i++) {
+		tnxfers++;
+
+		if (xfers[i].flags & I3C_PRIV_XFER_READ)
+			tnrx += DIV_ROUND_UP(xfers[i].len, 4);
+		else
+			tntx += DIV_ROUND_UP(xfers[i].len, 4);
+
+		if (!(xfers[i].flags & I3C_PRIV_XFER_STOP) &&
+		    i < nxfers - 1)
+			continue;
+
+		if (tnxfers > master->caps.cmdfifodepth ||
+		    tnrx > master->caps.rxfifodepth ||
+		    tntx > master->caps.txfifodepth)
+			return -ENOTSUPP;
+
+		tnxfers = 0;
+		tntx = 0;
+		tnrx = 0;
+	}
+
+	for (i = 0, j = 0; i < nxfers; i++) {
+		if (!(xfers[i].flags & I3C_PRIV_XFER_STOP) && i < nxfers - 1)
+			continue;
+
+		ret = cdns_i3c_master_contig_priv_xfers(master, xfers + j,
+							i + 1 - j);
+		if (ret)
+			return ret;
+
+		j = i;
+	}
+
+	return 0;
+}
+
+#define I3C_DDR_FIRST_DATA_WORD_PREAMBLE	0x2
+#define I3C_DDR_DATA_WORD_PREAMBLE		0x3
+
+#define I3C_DDR_PREAMBLE(p)			((p) << 18)
+
+static u32 prepare_ddr_word(u16 payload)
+{
+	u32 ret;
+	u16 pb;
+
+	ret = (u32)payload << 2;
+
+	/* Calculate parity. */
+	pb = (payload >> 15) ^ (payload >> 13) ^ (payload >> 11) ^
+	     (payload >> 9) ^ (payload >> 7) ^ (payload >> 5) ^
+	     (payload >> 3) ^ (payload >> 1);
+	ret |= (pb & 1) << 1;
+	pb = (payload >> 14) ^ (payload >> 12) ^ (payload >> 10) ^
+	     (payload >> 8) ^ (payload >> 6) ^ (payload >> 4) ^
+	     (payload >> 2) ^ payload ^ 1;
+	ret |= (pb & 1);
+
+	return ret;
+}
+
+static u32 prepare_ddr_data_word(u16 data, bool first)
+{
+	return prepare_ddr_word(data) | I3C_DDR_PREAMBLE(first ? 2 : 3);
+}
+
+#define I3C_DDR_READ_CMD	BIT(15)
+
+static u32 prepare_ddr_cmd_word(u16 cmd)
+{
+	return prepare_ddr_word(cmd) | I3C_DDR_PREAMBLE(1);
+}
+
+static u32 prepare_ddr_crc_word(u8 crc5)
+{
+	return (((u32)crc5 & 0x1f) << 9) | (0xc << 14) |
+	       I3C_DDR_PREAMBLE(1);
+}
+
+static u8 update_crc5(u8 crc5, u16 word)
+{
+	u8 crc0;
+	int i;
+
+	/*
+	 * crc0 = next_data_bit ^ crc[4]
+	 *                1         2            3       4
+	 * crc[4:0] = { crc[3:2], crc[1]^crc0, crc[0], crc0 }
+	 */
+	for (i = 0; i < 16; ++i) {
+		crc0 = ((word >> (15 - i)) ^ (crc5 >> 4)) & 0x1;
+		crc5 = ((crc5 << 1) & (0x18 | 0x2)) |
+		       (((crc5 >> 1) ^ crc0) << 2) | crc0;
+	}
+
+	return crc5 & 0x1F;
+}
+
+static int cdns_i3c_master_send_hdr_cmd(struct i3c_master_controller *m,
+					const struct i3c_hdr_cmd *cmds,
+					int ncmds)
+{
+	struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+	int ret, i, ntxwords = 1, nrxwords = 0;
+	struct cdns_i3c_xfer *xfer;
+	struct cdns_i3c_cmd *ccmd;
+	u16 cmdword, datain;
+	u32 checkword, word;
+	u32 *buf = NULL;
+	u8 crc5;
+
+	if (ncmds < 1)
+		return 0;
+
+	if (ncmds > 1 || cmds[0].ndatawords > CMD0_FIFO_PL_LEN_MAX)
+		return -ENOTSUPP;
+
+	if (cmds[0].mode != I3C_HDR_DDR)
+		return -ENOTSUPP;
+
+	cmdword = ((u16)cmds[0].code << 8) | (cmds[0].addr << 1);
+	if (cmdword & I3C_DDR_READ_CMD)
+		nrxwords += cmds[0].ndatawords + 1;
+	else
+		ntxwords += cmds[0].ndatawords + 1;
+
+	if (ntxwords > master->caps.txfifodepth ||
+	    nrxwords > master->caps.rxfifodepth)
+		return -ENOTSUPP;
+
+	buf = kzalloc((nrxwords + ntxwords) * sizeof(*buf), GFP_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+
+	xfer = cdns_i3c_master_alloc_xfer(master, 2);
+	if (!xfer) {
+		ret = -ENOMEM;
+		goto out_free_buf;
+	}
+
+	ccmd = &xfer->cmds[0];
+	ccmd->cmd1 = CMD1_FIFO_CCC(I3C_CCC_ENTHDR(0));
+	ccmd->cmd0 = CMD0_FIFO_IS_CCC;
+
+	ccmd = &xfer->cmds[1];
+
+	if (cmdword & I3C_DDR_READ_CMD) {
+		u16 pb;
+
+		pb = (cmdword >> 14) ^ (cmdword >> 12) ^ (cmdword >> 10) ^
+		     (cmdword >> 8) ^ (cmdword >> 6) ^ (cmdword >> 4) ^
+		     (cmdword >> 2);
+
+		if (pb & 1)
+			cmdword |= BIT(0);
+	}
+
+	ccmd->tx_len = ntxwords * sizeof(u32);
+	ccmd->tx_buf = buf;
+	ccmd->rx_len = nrxwords * sizeof(u32);
+	ccmd->rx_buf = buf + ntxwords;
+
+	buf[0] = prepare_ddr_cmd_word(cmdword);
+	crc5 = update_crc5(0x1f, cmdword);
+	for (i = 0; i < ntxwords - 2; i++) {
+		crc5 = update_crc5(crc5, cmds[0].data.out[i]);
+		buf[i + 1] = prepare_ddr_data_word(cmds[0].data.out[i], !i);
+	}
+
+	ccmd->cmd0 = CMD0_FIFO_IS_DDR | CMD0_FIFO_PL_LEN(ntxwords);
+
+	cdns_i3c_master_queue_xfer(master, xfer);
+	if (!wait_for_completion_timeout(&xfer->comp, msecs_to_jiffies(1000)))
+		cdns_i3c_master_unqueue_xfer(master, xfer);
+
+	if (xfer->isr == MST_INT_COMP) {
+		ret = 0;
+		for (i = 0; i < nrxwords; i++) {
+			word = ((u32 *)ccmd->rx_buf)[i];
+			datain = (word >> 2) & GENMASK(15, 0);
+			if (i < nrxwords - 1) {
+				checkword = prepare_ddr_data_word(datain, !i);
+				word &= GENMASK(19, 0);
+			} else {
+				checkword = prepare_ddr_crc_word(crc5);
+				word &= GENMASK(19, 7);
+			}
+
+			if (checkword != word) {
+				ret = -EIO;
+				break;
+			}
+
+			if (i < nrxwords - 1) {
+				crc5 = update_crc5(crc5, datain);
+				cmds[0].data.in[i] = datain;
+			}
+		}
+	} else if (!xfer->isr) {
+		ret = -ETIMEDOUT;
+	} else {
+		ret = -EIO;
+	}
+
+	cdns_i3c_master_free_xfer(xfer);
+
+out_free_buf:
+	kfree(buf);
+
+	return ret;
+}
+
+static int cdns_i3c_master_i2c_xfers(struct i3c_master_controller *m,
+				     const struct i2c_msg *xfers, int nxfers)
+{
+	struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+	unsigned int nrxwords = 0, ntxwords = 0;
+	struct cdns_i3c_xfer *xfer;
+	int i, ret = 0;
+
+	if (nxfers > master->caps.cmdfifodepth)
+		return -ENOTSUPP;
+
+	for (i = 0; i < nxfers; i++) {
+		if (xfers[i].len > CMD0_FIFO_PL_LEN_MAX)
+			return -ENOTSUPP;
+
+		if (xfers[i].flags & I2C_M_RD)
+			nrxwords += DIV_ROUND_UP(xfers[i].len, 4);
+		else
+			ntxwords += DIV_ROUND_UP(xfers[i].len, 4);
+	}
+
+	if (ntxwords > master->caps.txfifodepth ||
+	    nrxwords > master->caps.rxfifodepth)
+		return -ENOTSUPP;
+
+	xfer = cdns_i3c_master_alloc_xfer(master, nxfers);
+	if (!xfer)
+		return -ENOMEM;
+
+	for (i = 0; i < nxfers; i++) {
+		struct cdns_i3c_cmd *ccmd = &xfer->cmds[0];
+
+		ccmd->cmd0 = CMD0_FIFO_DEV_ADDR(xfers[i].addr) |
+			CMD0_FIFO_PL_LEN(xfers[i].len) |
+			CMD0_FIFO_PRIV_XMIT_MODE(XMIT_BURST_WITHOUT_SUBADDR);
+
+		if (xfers[i].flags & I2C_M_TEN)
+			ccmd->cmd0 |= CMD0_FIFO_IS_10B;
+
+		if (xfers[i].flags & I2C_M_RD) {
+			ccmd->cmd0 |= CMD0_FIFO_RNW;
+			ccmd->rx_buf = xfers[i].buf;
+			ccmd->rx_len = xfers[i].len;
+		} else {
+			ccmd->tx_buf = xfers[i].buf;
+			ccmd->tx_len = xfers[i].len;
+		}
+	}
+
+	cdns_i3c_master_queue_xfer(master, xfer);
+	if (!wait_for_completion_timeout(&xfer->comp, msecs_to_jiffies(1000)))
+		cdns_i3c_master_unqueue_xfer(master, xfer);
+
+	if (xfer->isr & MST_INT_NACK)
+		ret = -EIO;
+	else if (!(xfer->isr & MST_INT_COMP))
+		ret = -ETIMEDOUT;
+
+	cdns_i3c_master_free_xfer(xfer);
+
+	return ret;
+}
+
+struct cdns_i3c_i2c_dev_data {
+	u16 id;
+	s16 ibi;
+	struct i3c_generic_ibi_pool *ibi_pool;
+};
+
+static u32 prepare_rr0_dev_address(u32 addr)
+{
+	u32 ret = (addr << 1) & 0xff;
+
+	/* RR0[7:1] = addr[6:0] */
+	ret |= (addr & GENMASK(6, 0)) << 1;
+
+	/* RR0[15:13] = addr[9:7] */
+	ret |= (addr & GENMASK(9, 7)) << 6;
+
+	/* RR0[0] = ~XOR(addr[6:0]) */
+	if (!(hweight8(addr & 0x7f) & 1))
+		ret |= 1;
+
+	return ret;
+}
+
+static int cdns_i3c_master_attach_i3c_dev(struct cdns_i3c_master *master,
+					  struct i3c_device *dev)
+{
+	struct cdns_i3c_i2c_dev_data *data;
+	u32 val;
+
+	if (!master->free_dev_slots)
+		return -ENOMEM;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->id = ffs(master->free_dev_slots) - 1;
+	clear_bit(data->id, &master->free_dev_slots);
+	i3c_device_set_master_data(dev, data);
+
+	if (dev->info.dyn_addr)
+		val = prepare_rr0_dev_address(dev->info.dyn_addr) |
+		      DEV_ID_RR0_IS_I3C;
+	else
+		val = prepare_rr0_dev_address(dev->info.static_addr);
+
+	if (dev->info.dcr & I3C_BCR_HDR_CAP)
+		val |= DEV_ID_RR0_HDR_CAP;
+
+	writel(val, master->regs + DEV_ID_RR0(data->id));
+	writel(DEV_ID_RR1_PID_MSB(dev->info.pid),
+	       master->regs + DEV_ID_RR1(data->id));
+	writel(DEV_ID_RR2_DCR(dev->info.dcr) | DEV_ID_RR2_BCR(dev->info.bcr) |
+	       DEV_ID_RR2_PID_LSB(dev->info.pid),
+	       master->regs + DEV_ID_RR2(data->id));
+	writel(readl(master->regs + DEVS_CTRL) |
+	       DEVS_CTRL_DEV_ACTIVE(data->id), master->regs + DEVS_CTRL);
+
+	return 0;
+}
+
+static void cdns_i3c_master_detach_i3c_dev(struct cdns_i3c_master *master,
+					   struct i3c_device *dev)
+{
+	struct cdns_i3c_i2c_dev_data *data = i3c_device_get_master_data(dev);
+
+	if (!data)
+		return;
+
+	set_bit(data->id, &master->free_dev_slots);
+	writel(readl(master->regs + DEVS_CTRL) |
+	       DEVS_CTRL_DEV_CLR(data->id),
+	       master->regs + DEVS_CTRL);
+
+	i3c_device_set_master_data(dev, NULL);
+	kfree(data);
+}
+
+static int cdns_i3c_master_attach_i2c_dev(struct cdns_i3c_master *master,
+					  struct i2c_device *dev)
+{
+	struct cdns_i3c_i2c_dev_data *data;
+
+	if (!master->free_dev_slots)
+		return -ENOMEM;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->id = ffs(master->free_dev_slots) - 1;
+	clear_bit(data->id, &master->free_dev_slots);
+	i2c_device_set_master_data(dev, data);
+
+	writel(prepare_rr0_dev_address(dev->info.addr) |
+	       (dev->info.flags & I2C_CLIENT_TEN ? DEV_ID_RR0_LVR_EXT_ADDR : 0),
+	       master->regs + DEV_ID_RR0(data->id));
+	writel(dev->lvr, master->regs + DEV_ID_RR2(data->id));
+	writel(readl(master->regs + DEVS_CTRL) |
+	       DEVS_CTRL_DEV_ACTIVE(data->id),
+	       master->regs + DEVS_CTRL);
+
+	return 0;
+}
+
+static void cdns_i3c_master_detach_i2c_dev(struct cdns_i3c_master *master,
+					   struct i2c_device *dev)
+{
+	struct cdns_i3c_i2c_dev_data *data = i2c_device_get_master_data(dev);
+
+	if (!data)
+		return;
+
+	set_bit(data->id, &master->free_dev_slots);
+	writel(readl(master->regs + DEVS_CTRL) |
+	       DEVS_CTRL_DEV_CLR(data->id),
+	       master->regs + DEVS_CTRL);
+
+	i2c_device_set_master_data(dev, NULL);
+	kfree(data);
+}
+
+static void cdns_i3c_master_bus_cleanup(struct i3c_master_controller *m)
+{
+	struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+	struct i2c_device *i2cdev;
+	struct i3c_device *i3cdev;
+
+	cdns_i3c_master_disable(master);
+
+	i3c_bus_for_each_i2cdev(m->bus, i2cdev)
+		cdns_i3c_master_detach_i2c_dev(master, i2cdev);
+
+	i3c_bus_for_each_i3cdev(m->bus, i3cdev)
+		cdns_i3c_master_detach_i3c_dev(master, i3cdev);
+}
+
+static void cdns_i3c_master_dev_rr_to_info(struct cdns_i3c_master *master,
+					   unsigned int slot,
+					   struct i3c_device_info *info)
+{
+	u32 rr;
+
+	memset(info, 0, sizeof(*info));
+	rr = readl(master->regs + DEV_ID_RR0(slot));
+	info->dyn_addr = DEV_ID_RR0_GET_DEV_ADDR(rr);
+	rr = readl(master->regs + DEV_ID_RR2(slot));
+	info->dcr = rr;
+	info->bcr = rr >> 8;
+	info->pid = rr >> 16;
+	info->pid |= (u64)readl(master->regs + DEV_ID_RR1(slot)) << 16;
+}
+
+static int cdns_i3c_master_do_daa_locked(struct cdns_i3c_master *master)
+{
+	unsigned long i3c_lim_period, pres_step, i3c_scl_lim;
+	struct i3c_device_info devinfo;
+	struct i3c_device *i3cdev;
+	u32 prescl1, ctrl, devs;
+	int ret, slot, ncycles;
+
+	ret = i3c_master_entdaa_locked(&master->base);
+	if (ret)
+		return ret;
+
+	/* Now, add discovered devices to the bus. */
+	i3c_scl_lim = master->i3c_scl_lim;
+	devs = readl(master->regs + DEVS_CTRL);
+	for (slot = find_next_bit(&master->free_dev_slots, BITS_PER_LONG, 1);
+	     slot < BITS_PER_LONG;
+	     slot = find_next_bit(&master->free_dev_slots,
+				  BITS_PER_LONG, slot + 1)) {
+		struct cdns_i3c_i2c_dev_data *data;
+		u32 rr, max_fscl = 0;
+		u8 addr;
+
+		if (!(devs & DEVS_CTRL_DEV_ACTIVE(slot)))
+			continue;
+
+		data = kzalloc(sizeof(*data), GFP_KERNEL);
+		if (!data)
+			return -ENOMEM;
+
+		data->ibi = -1;
+		data->id = slot;
+		rr = readl(master->regs + DEV_ID_RR0(slot));
+		addr = DEV_ID_RR0_GET_DEV_ADDR(rr);
+		i3cdev = i3c_master_add_i3c_dev_locked(&master->base, addr);
+		if (IS_ERR(i3cdev))
+			return PTR_ERR(i3cdev);
+
+		i3c_device_get_info(i3cdev, &devinfo);
+		clear_bit(data->id, &master->free_dev_slots);
+		i3c_device_set_master_data(i3cdev, data);
+
+		max_fscl = max(I3C_CCC_MAX_SDR_FSCL(devinfo.max_read_ds),
+			       I3C_CCC_MAX_SDR_FSCL(devinfo.max_write_ds));
+		switch (max_fscl) {
+		case I3C_SDR_DR_FSCL_8MHZ:
+			max_fscl = 8000000;
+			break;
+		case I3C_SDR_DR_FSCL_6MHZ:
+			max_fscl = 6000000;
+			break;
+		case I3C_SDR_DR_FSCL_4MHZ:
+			max_fscl = 4000000;
+			break;
+		case I3C_SDR_DR_FSCL_2MHZ:
+			max_fscl = 2000000;
+			break;
+		case I3C_SDR_DR_FSCL_MAX:
+		default:
+			max_fscl = 0;
+			break;
+		}
+
+		if (max_fscl && (max_fscl < i3c_scl_lim || !i3c_scl_lim))
+			i3c_scl_lim = max_fscl;
+	}
+
+	i3c_master_defslvs_locked(&master->base);
+
+	pres_step = 1000000000 / (master->base.bus->scl_rate.i3c * 4);
+
+	/* No bus limitation to apply, bail out. */
+	if (!i3c_scl_lim ||
+	    (master->i3c_scl_lim && master->i3c_scl_lim <= i3c_scl_lim))
+		return 0;
+
+	/* Configure PP_LOW to meet I3C slave limitations. */
+	prescl1 = readl(master->regs + PRESCL_CTRL1) &
+		  ~PRESCL_CTRL1_PP_LOW_MASK;
+	ctrl = readl(master->regs + CTRL) & ~CTRL_DEV_EN;
+
+	i3c_lim_period = DIV_ROUND_UP(1000000000, i3c_scl_lim);
+	ncycles = DIV_ROUND_UP(i3c_lim_period, pres_step) - 4;
+	if (ncycles < 0)
+		ncycles = 0;
+	prescl1 |= PRESCL_CTRL1_PP_LOW(ncycles);
+
+	/* Disable I3C master before updating PRESCL_CTRL1. */
+	ret = cdns_i3c_master_disable(master);
+	if (!ret) {
+		writel(prescl1, master->regs + PRESCL_CTRL1);
+		master->i3c_scl_lim = i3c_scl_lim;
+	}
+	cdns_i3c_master_enable(master);
+
+	return ret;
+}
+
+static int cdns_i3c_master_bus_init(struct i3c_master_controller *m)
+{
+	struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+	unsigned long pres_step, sysclk_rate, max_i2cfreq;
+	u32 ctrl, prescl0, prescl1, pres, low;
+	struct i3c_device_info info = { };
+	struct i3c_ccc_events events;
+	struct i2c_device *i2cdev;
+	struct i3c_device *i3cdev;
+	int ret, slot, ncycles;
+	u8 last_addr = 0;
+
+	switch (m->bus->mode) {
+	case I3C_BUS_MODE_PURE:
+		ctrl = CTRL_PURE_BUS_MODE;
+		break;
+
+	case I3C_BUS_MODE_MIXED_FAST:
+		ctrl = CTRL_MIXED_FAST_BUS_MODE;
+		break;
+
+	case I3C_BUS_MODE_MIXED_SLOW:
+		ctrl = CTRL_MIXED_SLOW_BUS_MODE;
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	sysclk_rate = clk_get_rate(master->sysclk);
+	if (!sysclk_rate)
+		return -EINVAL;
+
+	pres = DIV_ROUND_UP(sysclk_rate, (m->bus->scl_rate.i3c * 4)) - 1;
+	if (pres > PRESCL_CTRL0_MAX)
+		return -ERANGE;
+
+	m->bus->scl_rate.i3c = sysclk_rate / ((pres + 1) * 4);
+
+	prescl0 = PRESCL_CTRL0_I3C(pres);
+
+	low = ((I3C_BUS_TLOW_OD_MIN_NS * sysclk_rate) / (pres + 1)) - 2;
+	prescl1 = PRESCL_CTRL1_OD_LOW(low);
+
+	max_i2cfreq = m->bus->scl_rate.i2c;
+
+	pres = (sysclk_rate / (max_i2cfreq * 5)) - 1;
+	if (pres > PRESCL_CTRL0_MAX)
+		return -ERANGE;
+
+	m->bus->scl_rate.i2c = sysclk_rate / ((pres + 1) * 5);
+
+	prescl0 |= PRESCL_CTRL0_I2C(pres);
+
+	writel(DEVS_CTRL_DEV_CLR_ALL, master->regs + DEVS_CTRL);
+
+	i3c_bus_for_each_i2cdev(m->bus, i2cdev) {
+		ret = cdns_i3c_master_attach_i2c_dev(master, i2cdev);
+		if (ret)
+			goto err_detach_devs;
+	}
+
+	writel(prescl0, master->regs + PRESCL_CTRL0);
+
+	/* Calculate OD and PP low. */
+	pres_step = 1000000000 / (m->bus->scl_rate.i3c * 4);
+	ncycles = DIV_ROUND_UP(I3C_BUS_TLOW_OD_MIN_NS, pres_step) - 2;
+	if (ncycles < 0)
+		ncycles = 0;
+	prescl1 = PRESCL_CTRL1_OD_LOW(ncycles);
+	writel(prescl1, master->regs + PRESCL_CTRL1);
+
+	i3c_bus_for_each_i3cdev(m->bus, i3cdev) {
+		ret = cdns_i3c_master_attach_i3c_dev(master, i3cdev);
+		if (ret)
+			goto err_detach_devs;
+	}
+
+	/* Get an address for the master. */
+	ret = i3c_master_get_free_addr(m, 0);
+	if (ret < 0)
+		goto err_detach_devs;
+
+	writel(prepare_rr0_dev_address(ret) | DEV_ID_RR0_IS_I3C,
+	       master->regs + DEV_ID_RR0(0));
+
+	cdns_i3c_master_dev_rr_to_info(master, 0, &info);
+	if (info.bcr & I3C_BCR_HDR_CAP)
+		info.hdr_cap = I3C_CCC_HDR_MODE(I3C_HDR_DDR);
+
+	ret = i3c_master_set_info(&master->base, &info);
+	if (ret)
+		goto err_detach_devs;
+
+	/* Prepare RR slots before lauching DAA. */
+	for (slot = find_next_bit(&master->free_dev_slots, BITS_PER_LONG, 1);
+	     slot < BITS_PER_LONG;
+	     slot = find_next_bit(&master->free_dev_slots,
+				  BITS_PER_LONG, slot + 1)) {
+		ret = i3c_master_get_free_addr(m, last_addr + 1);
+		if (ret < 0)
+			goto err_disable_master;
+
+		last_addr = ret;
+		writel(prepare_rr0_dev_address(last_addr) | DEV_ID_RR0_IS_I3C,
+		       master->regs + DEV_ID_RR0(slot));
+		writel(0, master->regs + DEV_ID_RR1(slot));
+		writel(0, master->regs + DEV_ID_RR2(slot));
+	}
+
+	/*
+	 * Enable Hot-Join and when a Hot-Join request happen, disable all
+	 * events coming from this device.
+	 *
+	 * We will issue ENTDAA afterwards from the threaded IRQ handler.
+	 */
+	ctrl |= CTRL_HJ_ACK | CTRL_HJ_DISEC | CTRL_HALT_EN;
+	writel(ctrl, master->regs + CTRL);
+
+	cdns_i3c_master_enable(master);
+
+	/*
+	 * Reset all dynamic addresses on the bus, because we don't know what
+	 * happened before this point (the bootloader may have assigned dynamic
+	 * addresses that we're not aware of).
+	 */
+	ret = i3c_master_rstdaa_locked(m, I3C_BROADCAST_ADDR);
+	if (ret)
+		goto err_disable_master;
+
+	/* Disable all slave events (interrupts) before starting DAA. */
+	events.events = I3C_CCC_EVENT_SIR | I3C_CCC_EVENT_MR |
+			I3C_CCC_EVENT_HJ;
+	ret = i3c_master_disec_locked(m, I3C_BROADCAST_ADDR, &events);
+	if (ret)
+		goto err_disable_master;
+
+	ret = cdns_i3c_master_do_daa_locked(master);
+	if (ret < 0)
+		goto err_disable_master;
+
+	/* Unmask Hot-Join and Marstership request interrupts. */
+	events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR;
+	ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, &events);
+	if (ret)
+		pr_info("Failed to re-enable H-J");
+
+	writel(MST_INT_HJ_REQ, master->regs + MST_IER);
+	return 0;
+
+err_disable_master:
+	cdns_i3c_master_disable(master);
+
+err_detach_devs:
+	cdns_i3c_master_bus_cleanup(m);
+
+	return ret;
+}
+
+static void cnds_i3c_master_demux_ibis(struct cdns_i3c_master *master)
+{
+	unsigned int i, sirstatus;
+
+	writel(MST_INT_IBI_REQ, master->regs + MST_ICR);
+	sirstatus = readl(master->regs + SIR_STATUS);
+
+	/*
+	 * The IBI logic is broken, and if more than one device sent an
+	 * IBI, there's simply no way we can determine which one came in first.
+	 * In this case, drop all IBIs and flush the FIFO.
+	 */
+	if (hweight32(sirstatus) > 1) {
+		writel(readl(master->regs + CTRL) & ~CTRL_DEV_EN,
+		       master->regs + CTRL);
+		writel(FLUSH_IBI_FIFO, master->regs + FLUSH_CTRL);
+		writel(sirstatus, master->regs + SIR_STATUS);
+		writel(readl(master->regs + CTRL) | CTRL_DEV_EN,
+		       master->regs + CTRL);
+		return;
+	}
+
+	spin_lock(&master->ibi.lock);
+	for (i = 0; i < master->ibi.num_slots; i++) {
+		struct i3c_device *dev = master->ibi.slots[i];
+		struct cdns_i3c_i2c_dev_data *data;
+		struct i3c_ibi_slot *slot;
+		unsigned int len, j;
+		u8 *buf;
+		u32 tmp;
+
+		if (!(sirstatus & BIT(i)) || !dev)
+			continue;
+
+		data = i3c_device_get_master_data(dev);
+		slot = i3c_generic_ibi_get_free_slot(data->ibi_pool);
+		if (!slot)
+			continue;
+
+		buf = slot->data;
+		for (len = 0; len < dev->ibi->max_payload_len;) {
+			tmp = readl(master->regs + IBI_DATA_FIFO);
+			if (readl(master->regs + MST_ISR) & MST_INT_IBI_UNF) {
+				writel(MST_INT_IBI_UNF, master->regs + MST_ICR);
+				break;
+			}
+
+			for (j = 0; j < 4 && len < dev->ibi->max_payload_len;
+			     j++, len++)
+				buf[len] = tmp >> (j * 8);
+		}
+
+		slot->len = len;
+		i3c_device_queue_ibi(dev, slot);
+	}
+
+	spin_unlock(&master->ibi.lock);
+
+	writel(FLUSH_IBI_FIFO, master->regs + FLUSH_CTRL);
+	writel(sirstatus, master->regs + SIR_STATUS);
+}
+
+static irqreturn_t cdns_i3c_master_interrupt(int irq, void *data)
+{
+	struct cdns_i3c_master *master = data;
+	u32 status;
+
+	status = readl(master->regs + MST_ISR);
+	if (!(status & readl(master->regs + MST_IMR)))
+		return IRQ_NONE;
+
+	spin_lock(&master->xferqueue.lock);
+	cdns_i3c_master_end_xfer_locked(master, status);
+	spin_unlock(&master->xferqueue.lock);
+
+	if (status & MST_INT_HJ_REQ) {
+		writel(MST_INT_HJ_REQ, master->regs + MST_IDR);
+		queue_work(master->base.wq, &master->hj_work);
+	}
+
+	if (status & MST_INT_IBI_REQ)
+		cnds_i3c_master_demux_ibis(master);
+
+	return IRQ_HANDLED;
+}
+
+int cdns_i3c_master_disable_ibi(struct i3c_master_controller *m,
+				struct i3c_device *dev)
+{
+	struct i3c_ccc_events events = { .events = I3C_CCC_EVENT_SIR };
+	struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+	struct cdns_i3c_i2c_dev_data *data = i3c_device_get_master_data(dev);
+	struct i3c_device_info devinfo;
+	unsigned long flags;
+	u32 sirmap;
+	int ret;
+
+	i3c_bus_normaluse_lock(m->bus);
+	i3c_device_get_info(dev, &devinfo);
+	ret = i3c_master_disec_locked(m, devinfo.dyn_addr, &events);
+	if (ret)
+		goto out;
+
+	spin_lock_irqsave(&master->ibi.lock, flags);
+	sirmap = readl(master->regs + SIR_MAP_DEV_REG(data->ibi));
+	sirmap &= ~SIR_MAP_DEV_CONF_MASK(data->ibi);
+	sirmap |= SIR_MAP_DEV_CONF(data->ibi,
+				   SIR_MAP_DEV_DA(I3C_BROADCAST_ADDR));
+	writel(sirmap, master->regs + SIR_MAP_DEV_REG(data->ibi));
+	spin_unlock_irqrestore(&master->ibi.lock, flags);
+
+out:
+	i3c_bus_normaluse_unlock(m->bus);
+
+	return ret;
+}
+
+int cdns_i3c_master_enable_ibi(struct i3c_master_controller *m,
+			       struct i3c_device *dev)
+{
+	struct i3c_ccc_events events = { .events = I3C_CCC_EVENT_SIR };
+	struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+	struct cdns_i3c_i2c_dev_data *data = i3c_device_get_master_data(dev);
+	struct i3c_device_info devinfo;
+	unsigned long flags;
+	u32 sircfg, sirmap;
+	int ret;
+
+	i3c_bus_normaluse_lock(m->bus);
+	i3c_device_get_info(dev, &devinfo);
+	spin_lock_irqsave(&master->ibi.lock, flags);
+	sirmap = readl(master->regs + SIR_MAP_DEV_REG(data->ibi));
+	sirmap &= ~SIR_MAP_DEV_CONF_MASK(data->ibi);
+	sircfg = SIR_MAP_DEV_ROLE(devinfo.bcr >> 6) |
+		 SIR_MAP_DEV_DA(devinfo.dyn_addr) |
+		 SIR_MAP_DEV_PL(devinfo.max_ibi_len) |
+		 SIR_MAP_DEV_ACK;
+	if (devinfo.bcr & I3C_BCR_MAX_DATA_SPEED_LIM)
+		sircfg |= SIR_MAP_DEV_SLOW;
+	sirmap |= SIR_MAP_DEV_CONF(data->ibi, sircfg);
+	writel(sirmap, master->regs + SIR_MAP_DEV_REG(data->ibi));
+	spin_unlock_irqrestore(&master->ibi.lock, flags);
+
+	ret = i3c_master_enec_locked(m, devinfo.dyn_addr, &events);
+	if (ret)
+		goto err_reset_sircfg;
+	i3c_bus_normaluse_unlock(m->bus);
+
+	return 0;
+
+err_reset_sircfg:
+	spin_lock_irqsave(&master->ibi.lock, flags);
+	sirmap = readl(master->regs + SIR_MAP_DEV_REG(data->ibi));
+	sirmap &= ~SIR_MAP_DEV_CONF_MASK(data->ibi);
+	sirmap |= SIR_MAP_DEV_CONF(data->ibi,
+				   SIR_MAP_DEV_DA(I3C_BROADCAST_ADDR));
+	writel(sirmap, master->regs + SIR_MAP_DEV_REG(data->ibi));
+	spin_unlock_irqrestore(&master->ibi.lock, flags);
+	i3c_bus_normaluse_unlock(m->bus);
+
+	return ret;
+}
+
+int cdns_i3c_master_request_ibi(struct i3c_master_controller *m,
+				struct i3c_device *dev,
+				const struct i3c_ibi_setup *req)
+{
+	struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+	struct cdns_i3c_i2c_dev_data *data = i3c_device_get_master_data(dev);
+	unsigned long flags;
+	unsigned int i;
+
+	data->ibi_pool = i3c_generic_ibi_alloc_pool(dev, req);
+	if (IS_ERR(data->ibi_pool))
+		return PTR_ERR(data->ibi_pool);
+
+	spin_lock_irqsave(&master->ibi.lock, flags);
+	for (i = 0; i < master->ibi.num_slots; i++) {
+		if (!master->ibi.slots[i]) {
+			data->ibi = i;
+			master->ibi.slots[i] = dev;
+			break;
+		}
+	}
+	spin_unlock_irqrestore(&master->ibi.lock, flags);
+
+	if (i < master->ibi.num_slots)
+		return 0;
+
+	i3c_generic_ibi_free_pool(data->ibi_pool);
+	data->ibi_pool = NULL;
+
+	return -ENOSPC;
+}
+
+static void cdns_i3c_master_free_ibi(struct i3c_master_controller *m,
+				     struct i3c_device *dev)
+{
+	struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+	struct cdns_i3c_i2c_dev_data *data = i3c_device_get_master_data(dev);
+	unsigned long flags;
+
+	spin_lock_irqsave(&master->ibi.lock, flags);
+	master->ibi.slots[data->ibi] = NULL;
+	data->ibi = -1;
+	spin_unlock_irqrestore(&master->ibi.lock, flags);
+
+	i3c_generic_ibi_free_pool(data->ibi_pool);
+}
+
+static void cdns_i3c_master_recycle_ibi_slot(struct i3c_master_controller *m,
+					     struct i3c_device *dev,
+					     struct i3c_ibi_slot *slot)
+{
+	struct cdns_i3c_i2c_dev_data *data = i3c_device_get_master_data(dev);
+
+	i3c_generic_ibi_recycle_slot(data->ibi_pool, slot);
+}
+
+static const struct i3c_master_controller_ops cdns_i3c_master_ops = {
+	.bus_init = cdns_i3c_master_bus_init,
+	.bus_cleanup = cdns_i3c_master_bus_cleanup,
+	.supports_ccc_cmd = cdns_i3c_master_supports_ccc_cmd,
+	.send_ccc_cmd = cdns_i3c_master_send_ccc_cmd,
+	.send_hdr_cmds = cdns_i3c_master_send_hdr_cmd,
+	.priv_xfers = cdns_i3c_master_priv_xfers,
+	.i2c_xfers = cdns_i3c_master_i2c_xfers,
+	.enable_ibi = cdns_i3c_master_enable_ibi,
+	.disable_ibi = cdns_i3c_master_disable_ibi,
+	.request_ibi = cdns_i3c_master_request_ibi,
+	.free_ibi = cdns_i3c_master_free_ibi,
+	.recycle_ibi_slot = cdns_i3c_master_recycle_ibi_slot,
+};
+
+static void cdns_i3c_master_hj(struct work_struct *work)
+{
+	struct cdns_i3c_master *master = container_of(work,
+						      struct cdns_i3c_master,
+						      hj_work);
+	struct i3c_bus *bus = i3c_master_get_bus(&master->base);
+	u32 status;
+
+	status = readl(master->regs + MST_ISR);
+	if (!(status & MST_INT_HJ_REQ))
+		return;
+
+	i3c_bus_maintenance_lock(bus);
+	writel(MST_INT_HJ_REQ, master->regs + MST_ICR);
+	cdns_i3c_master_do_daa_locked(master);
+	i3c_master_register_new_i3c_devs(&master->base);
+	i3c_bus_maintenance_unlock(bus);
+}
+
+static int cdns_i3c_master_probe(struct platform_device *pdev)
+{
+	struct cdns_i3c_master *master;
+	struct resource *res;
+	int ret, irq;
+	u32 val;
+
+	master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
+	if (!master)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	master->regs = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(master->regs))
+		return PTR_ERR(master->regs);
+
+	master->pclk = devm_clk_get(&pdev->dev, "pclk");
+	if (IS_ERR(master->pclk))
+		return PTR_ERR(master->pclk);
+
+	master->sysclk = devm_clk_get(&pdev->dev, "sysclk");
+	if (IS_ERR(master->pclk))
+		return PTR_ERR(master->pclk);
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		return irq;
+
+	ret = clk_prepare_enable(master->pclk);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(master->sysclk);
+	if (ret)
+		goto err_disable_pclk;
+
+	if (readl(master->regs + DEV_ID) != DEV_ID_I3C_MASTER) {
+		ret = -EINVAL;
+		goto err_disable_sysclk;
+	}
+
+	spin_lock_init(&master->xferqueue.lock);
+	INIT_LIST_HEAD(&master->xferqueue.list);
+
+	INIT_WORK(&master->hj_work, cdns_i3c_master_hj);
+	writel(0xffffffff, master->regs + MST_IDR);
+	writel(0xffffffff, master->regs + SLV_IDR);
+	ret = devm_request_irq(&pdev->dev, irq, cdns_i3c_master_interrupt, 0,
+			       dev_name(&pdev->dev), master);
+	if (ret)
+		goto err_disable_sysclk;
+
+	platform_set_drvdata(pdev, master);
+
+	val = readl(master->regs + CONF_STATUS0);
+
+	/* Device ID0 is reserved to describe this master. */
+	master->free_dev_slots = GENMASK(CONF_STATUS0_DEVS_NUM(val), 1);
+
+	val = readl(master->regs + CONF_STATUS1);
+	master->caps.cmdfifodepth = CONF_STATUS1_CMD_DEPTH(val);
+	master->caps.rxfifodepth = CONF_STATUS1_RX_DEPTH(val);
+	master->caps.txfifodepth = CONF_STATUS1_TX_DEPTH(val);
+
+	spin_lock_init(&master->ibi.lock);
+	master->ibi.num_slots = CONF_STATUS1_IBI_HW_RES(val);
+	master->ibi.slots = devm_kzalloc(&pdev->dev,
+					 sizeof(*master->ibi.slots) *
+					 master->ibi.num_slots,
+					 GFP_KERNEL);
+	if (!master->ibi.slots)
+		goto err_disable_sysclk;
+
+	writel(MST_INT_IBI_REQ, master->regs + MST_IER);
+
+	ret = i3c_master_register(&master->base, &pdev->dev,
+				  &cdns_i3c_master_ops, false);
+	if (ret)
+		goto err_disable_sysclk;
+
+	return 0;
+
+err_disable_sysclk:
+	clk_disable_unprepare(master->sysclk);
+
+err_disable_pclk:
+	clk_disable_unprepare(master->pclk);
+
+	return ret;
+}
+
+static int cdns_i3c_master_remove(struct platform_device *pdev)
+{
+	struct cdns_i3c_master *master = platform_get_drvdata(pdev);
+	int ret;
+
+	ret = i3c_master_unregister(&master->base);
+	if (ret)
+		return ret;
+
+	clk_disable_unprepare(master->sysclk);
+	clk_disable_unprepare(master->pclk);
+
+	return 0;
+}
+
+static const struct of_device_id cdns_i3c_master_of_ids[] = {
+	{ .compatible = "cdns,i3c-master" },
+	{ /* sentinel */ },
+};
+
+static struct platform_driver cdns_i3c_master = {
+	.probe = cdns_i3c_master_probe,
+	.remove = cdns_i3c_master_remove,
+	.driver = {
+		.name = "cdns-i3c-master",
+		.of_match_table = cdns_i3c_master_of_ids,
+	},
+};
+module_platform_driver(cdns_i3c_master);
+
+MODULE_AUTHOR("Boris Brezillon <boris.brezillon@free-electrons.com>");
+MODULE_DESCRIPTION("Cadence I3C master driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:cdns-i3c-master");
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* [PATCH v2 7/7] dt-bindings: i3c: Document Cadence I3C master bindings
  2017-12-14 15:16 [PATCH v2 0/7] Add the I3C subsystem Boris Brezillon
                   ` (5 preceding siblings ...)
  2017-12-14 15:16 ` [PATCH v2 6/7] i3c: master: Add driver for Cadence IP Boris Brezillon
@ 2017-12-14 15:16 ` Boris Brezillon
  2018-02-22 15:00 ` [PATCH v2 0/7] Add the I3C subsystem Vitor Soares
  7 siblings, 0 replies; 50+ messages in thread
From: Boris Brezillon @ 2017-12-14 15:16 UTC (permalink / raw)
  To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij,
	Boris Brezillon

Document Cadence I3C master DT bindings.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
 .../devicetree/bindings/i3c/cdns,i3c-master.txt    | 45 ++++++++++++++++++++++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt

diff --git a/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
new file mode 100644
index 000000000000..f9e4af4ff1c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
@@ -0,0 +1,45 @@
+Bindings for cadence I3C master block
+=====================================
+
+Required properties:
+--------------------
+- compatible: shall be "cdns,i3c-master"
+- clocks: shall reference the pclk and sysclk
+- clock-names: shall contain "pclk" and "sysclk"
+- interrupts: the interrupt line connected to this I3C master
+- reg: I3C master registers
+
+Mandatory properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- #address-cells: shall be set to 1
+- #size-cells: shall be set to 0
+
+Optional properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- i2c-scl-frequency
+- i3c-scl-frequency
+
+I3C device connected on the bus follow the generic description (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details).
+
+Example:
+
+	i3c-master@0d040000 {
+		compatible = "cdns,i3c-master";
+		clocks = <&coreclock>, <&i3csysclock>;
+		clock-names = "pclk", "sysclk";
+		interrupts = <3 0>;
+		reg = <0x0d040000 0x1000>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		i2c-scl-frequency = <100000>;
+
+		nunchuk: nunchuk@52 {
+			compatible = "nintendo,nunchuk";
+			reg = <0x52>;
+			i3c-lvr = <0x10>;
+		};
+	};
+
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
  2017-12-14 15:16 ` [PATCH v2 5/7] dt-bindings: i3c: Document core bindings Boris Brezillon
@ 2017-12-14 16:24   ` Geert Uytterhoeven
  2017-12-14 21:47   ` Peter Rosin
  2017-12-16 17:20   ` Rob Herring
  2 siblings, 0 replies; 50+ messages in thread
From: Geert Uytterhoeven @ 2017-12-14 16:24 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Wolfram Sang, Linux I2C, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	Linux Kernel Mailing List, Vitor Soares, Linus Walleij

Hi Boris,

On Thu, Dec 14, 2017 at 4:16 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> A new I3C subsystem has been added and a generic description has been
> created to represent the I3C bus and the devices connected on it.
>
> Document this generic representation.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>

Thanks for your patch!

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> @@ -0,0 +1,128 @@
> +Generic device tree bindings for I3C busses
> +===========================================
> +
> +This document describes generic bindings that should be used to describe I3C
> +busses in a device tree.
> +
> +Required properties
> +-------------------
> +
> +- #address-cells  - should be <1>. Read more about addresses below.
> +- #size-cells     - should be <0>.
> +- compatible      - name of I3C bus controller following generic names
> +                   recommended practice.
> +
> +For other required properties e.g. to describe register sets,
> +clocks, etc. check the binding documentation of the specific driver.
> +
> +Optional properties
> +-------------------
> +
> +These properties may not be supported by all I3C master drivers. Each I3C
> +master bindings should specify which of them are supported.
> +
> +- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
> +                    transfers. When undefined the core set it to 12.5MHz.

sets

> +
> +- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
> +                    transfers. When undefined, the core looks at LVR values

LVR (Legacy I2C Virtual Register)

> +                    of I2C devices described in the device tree to determine
> +                    the maximum I2C frequency.
> +
> +I2C devices
> +===========
> +
> +Each I2C device connected to the bus should be described in a subnode with
> +the following properties:

This colon looks a bit funny here, as below is a sentence, not a list.

> +
> +All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
> +valid here.

Perhaps rewrite as:

  Each I2C device connected to the bus should be described in a subnode with
  properties.  All properties described in
  Documentation/devicetree/bindings/i2c/i2c.txt are valid here, but several
  new properties have been added.

> +
> +New required properties:
> +------------------------
> +- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
> +          describing device capabilities as described in the I3C
> +          specification.
> +
> +          bit[31:8]: unused
> +          bit[7:5]: I2C device index. Possible values
> +           * 0: I2C device has a 50 ns spike filter
> +           * 1: I2C device does not have a 50 ns spike filter but supports high
> +                frequency on SCL
> +           * 2: I2C device does not have a 50 ns spike filter and is not
> +                tolerant to high frequencies
> +           * 3-7: reserved
> +
> +          bit[4]: tell whether the device operates in FM or FM+ mode
> +           * 0: FM+ mode
> +           * 1: FM mode

As this is the only reference to "FM", perhaps clarify the acronym, like you
do for DAA below.

> +
> +          bit[3:0]: device type
> +           * 0-15: reserved
> +
> +I3C devices
> +===========
> +
> +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
> +are thus discoverable. So, by default, I3C devices do not have to be described
> +in the device tree.
> +This being said, one might want to attach extra resources to these devices,
> +and those resources may have to be described in the device tree, which in turn
> +means we have to describe I3C devices.
> +
> +Another use case for describing an I3C device in the device tree is when this
> +I3C device has a static address and we want to assign it a specific dynamic
> +address before the DAA takes place (so that other devices on the bus can't
> +take this dynamic address).
> +
> +Required properties
> +-------------------
> +- i3c-pid: PID (Provisional ID). 64-bit property which is used to match a
> +          device discovered during DAA with its device tree definition. The
> +          PID is supposed to be unique on a given bus, which guarantees a 1:1
> +          match. This property becomes optional if a reg property is defined,
> +          meaning that the device has a static address.
> +
> +Optional properties
> +-------------------
> +- reg: static address. Only valid is the device has a static address.

if


-- 
Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 6/7] i3c: master: Add driver for Cadence IP
  2017-12-14 15:16 ` [PATCH v2 6/7] i3c: master: Add driver for Cadence IP Boris Brezillon
@ 2017-12-14 19:54   ` Randy Dunlap
  2017-12-14 20:17     ` Boris Brezillon
  0 siblings, 1 reply; 50+ messages in thread
From: Randy Dunlap @ 2017-12-14 19:54 UTC (permalink / raw)
  To: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij

On 12/14/2017 07:16 AM, Boris Brezillon wrote:
> Add a driver for Cadence I3C master IP.
> 
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Changes in v2:
> - Add basic IBI support. Note that the IP is not really reliable with
>   regards to IBI because you can't extract IBI payloads as soon as you
>   have more than one IBI waiting in the HW queue. This is something
>   that will hopefully be addressed in future revisions of this IP
> - Add a simple xfer queueing mechanism to optimize message queuing.
> - Fix a few bugs
> - Add support for Hot Join
> ---
>  drivers/i3c/master/Kconfig           |    5 +
>  drivers/i3c/master/Makefile          |    1 +
>  drivers/i3c/master/i3c-master-cdns.c | 1797 ++++++++++++++++++++++++++++++++++
>  3 files changed, 1803 insertions(+)
>  create mode 100644 drivers/i3c/master/i3c-master-cdns.c
> 
> diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
> index e69de29bb2d1..56b9a18543b2 100644
> --- a/drivers/i3c/master/Kconfig
> +++ b/drivers/i3c/master/Kconfig
> @@ -0,0 +1,5 @@
> +config CDNS_I3C_MASTER
> +	tristate "Cadence I3C master driver"
> +	depends on I3C
> +	help
> +	  Enable this driver if you want to support Cadence I3C master block.
> diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
> index e69de29bb2d1..4c4304aa9534 100644
> --- a/drivers/i3c/master/Makefile
> +++ b/drivers/i3c/master/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_CDNS_I3C_MASTER)		+= i3c-master-cdns.o
> diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c
> new file mode 100644
> index 000000000000..3e3ef37c01c2
> --- /dev/null
> +++ b/drivers/i3c/master/i3c-master-cdns.c
> @@ -0,0 +1,1797 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> + */
> +

Rule #1 from submit-checklist.rst:
1) If you use a facility then #include the file that defines/declares
   that facility.  Don't depend on other header files pulling in ones
   that you use.


#include <linux/bitops.h>
for BIT(x) and hweight8() and clear_bit() and find_next_bit()
and hweight32()

> +#include <linux/clk.h>

#include <linux/err.h>
for IS_ERR(), PTR_ERR()

#include <linux/errno.h>
for error codes

> +#include <linux/i3c/master.h>
> +#include <linux/interrupt.h>

#include <linux/io.h>
for writel()

> +#include <linux/iopoll.h>

#include <linux/ioport.h>
for IORESOURCE_MEM

#include <linux/kernel.h>
for DIV_ROUND_UP()

#include <linux/list.h>
for list() macros and INIT_LIST_HEAD()

> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>

#include <linux/spinlock.h>

#include <linux/workqueue.h>
for workqueue functions and INIT_WORK()

> +
> +#define DEV_ID				0x0
> +#define DEV_ID_I3C_MASTER		0x5034

[snip]



> +#define I3C_DDR_FIRST_DATA_WORD_PREAMBLE	0x2
> +#define I3C_DDR_DATA_WORD_PREAMBLE		0x3
> +
> +#define I3C_DDR_PREAMBLE(p)			((p) << 18)
> +
> +static u32 prepare_ddr_word(u16 payload)
> +{
> +	u32 ret;
> +	u16 pb;
> +
> +	ret = (u32)payload << 2;
> +
> +	/* Calculate parity. */
> +	pb = (payload >> 15) ^ (payload >> 13) ^ (payload >> 11) ^
> +	     (payload >> 9) ^ (payload >> 7) ^ (payload >> 5) ^
> +	     (payload >> 3) ^ (payload >> 1);
> +	ret |= (pb & 1) << 1;
> +	pb = (payload >> 14) ^ (payload >> 12) ^ (payload >> 10) ^
> +	     (payload >> 8) ^ (payload >> 6) ^ (payload >> 4) ^
> +	     (payload >> 2) ^ payload ^ 1;
> +	ret |= (pb & 1);
> +
> +	return ret;
> +}
> +
> +static u32 prepare_ddr_data_word(u16 data, bool first)
> +{
> +	return prepare_ddr_word(data) | I3C_DDR_PREAMBLE(first ? 2 : 3);

Just defined macros for 2 & 3 above. Use them instead of magic numbers?

> +}
> +
> +#define I3C_DDR_READ_CMD	BIT(15)
> +
> +static u32 prepare_ddr_cmd_word(u16 cmd)
> +{
> +	return prepare_ddr_word(cmd) | I3C_DDR_PREAMBLE(1);
> +}
> +
> +static u32 prepare_ddr_crc_word(u8 crc5)
> +{
> +	return (((u32)crc5 & 0x1f) << 9) | (0xc << 14) |
> +	       I3C_DDR_PREAMBLE(1);
> +}
> +
> +static u8 update_crc5(u8 crc5, u16 word)
> +{
> +	u8 crc0;
> +	int i;
> +
> +	/*
> +	 * crc0 = next_data_bit ^ crc[4]
> +	 *                1         2            3       4
> +	 * crc[4:0] = { crc[3:2], crc[1]^crc0, crc[0], crc0 }
> +	 */
> +	for (i = 0; i < 16; ++i) {
> +		crc0 = ((word >> (15 - i)) ^ (crc5 >> 4)) & 0x1;
> +		crc5 = ((crc5 << 1) & (0x18 | 0x2)) |
> +		       (((crc5 >> 1) ^ crc0) << 2) | crc0;
> +	}
> +
> +	return crc5 & 0x1F;
> +}
> +

[snip]



> +static int cdns_i3c_master_do_daa_locked(struct cdns_i3c_master *master)
> +{
> +	unsigned long i3c_lim_period, pres_step, i3c_scl_lim;
> +	struct i3c_device_info devinfo;
> +	struct i3c_device *i3cdev;
> +	u32 prescl1, ctrl, devs;
> +	int ret, slot, ncycles;
> +
> +	ret = i3c_master_entdaa_locked(&master->base);
> +	if (ret)
> +		return ret;
> +
> +	/* Now, add discovered devices to the bus. */
> +	i3c_scl_lim = master->i3c_scl_lim;
> +	devs = readl(master->regs + DEVS_CTRL);
> +	for (slot = find_next_bit(&master->free_dev_slots, BITS_PER_LONG, 1);
> +	     slot < BITS_PER_LONG;
> +	     slot = find_next_bit(&master->free_dev_slots,
> +				  BITS_PER_LONG, slot + 1)) {
> +		struct cdns_i3c_i2c_dev_data *data;
> +		u32 rr, max_fscl = 0;
> +		u8 addr;
> +
> +		if (!(devs & DEVS_CTRL_DEV_ACTIVE(slot)))
> +			continue;
> +
> +		data = kzalloc(sizeof(*data), GFP_KERNEL);
> +		if (!data)
> +			return -ENOMEM;
> +
> +		data->ibi = -1;
> +		data->id = slot;
> +		rr = readl(master->regs + DEV_ID_RR0(slot));
> +		addr = DEV_ID_RR0_GET_DEV_ADDR(rr);
> +		i3cdev = i3c_master_add_i3c_dev_locked(&master->base, addr);
> +		if (IS_ERR(i3cdev))
> +			return PTR_ERR(i3cdev);
> +
> +		i3c_device_get_info(i3cdev, &devinfo);
> +		clear_bit(data->id, &master->free_dev_slots);
> +		i3c_device_set_master_data(i3cdev, data);
> +
> +		max_fscl = max(I3C_CCC_MAX_SDR_FSCL(devinfo.max_read_ds),
> +			       I3C_CCC_MAX_SDR_FSCL(devinfo.max_write_ds));
> +		switch (max_fscl) {
> +		case I3C_SDR_DR_FSCL_8MHZ:
> +			max_fscl = 8000000;
> +			break;
> +		case I3C_SDR_DR_FSCL_6MHZ:
> +			max_fscl = 6000000;
> +			break;
> +		case I3C_SDR_DR_FSCL_4MHZ:
> +			max_fscl = 4000000;
> +			break;
> +		case I3C_SDR_DR_FSCL_2MHZ:
> +			max_fscl = 2000000;
> +			break;
> +		case I3C_SDR_DR_FSCL_MAX:
> +		default:
> +			max_fscl = 0;
> +			break;
> +		}
> +
> +		if (max_fscl && (max_fscl < i3c_scl_lim || !i3c_scl_lim))
> +			i3c_scl_lim = max_fscl;
> +	}
> +
> +	i3c_master_defslvs_locked(&master->base);
> +
> +	pres_step = 1000000000 / (master->base.bus->scl_rate.i3c * 4);

Does that build OK on 32-bit target arch?

> +
> +	/* No bus limitation to apply, bail out. */
> +	if (!i3c_scl_lim ||
> +	    (master->i3c_scl_lim && master->i3c_scl_lim <= i3c_scl_lim))
> +		return 0;
> +
> +	/* Configure PP_LOW to meet I3C slave limitations. */
> +	prescl1 = readl(master->regs + PRESCL_CTRL1) &
> +		  ~PRESCL_CTRL1_PP_LOW_MASK;
> +	ctrl = readl(master->regs + CTRL) & ~CTRL_DEV_EN;
> +
> +	i3c_lim_period = DIV_ROUND_UP(1000000000, i3c_scl_lim);
> +	ncycles = DIV_ROUND_UP(i3c_lim_period, pres_step) - 4;
> +	if (ncycles < 0)
> +		ncycles = 0;
> +	prescl1 |= PRESCL_CTRL1_PP_LOW(ncycles);
> +
> +	/* Disable I3C master before updating PRESCL_CTRL1. */
> +	ret = cdns_i3c_master_disable(master);
> +	if (!ret) {
> +		writel(prescl1, master->regs + PRESCL_CTRL1);
> +		master->i3c_scl_lim = i3c_scl_lim;
> +	}
> +	cdns_i3c_master_enable(master);
> +
> +	return ret;
> +}
> +
> +static int cdns_i3c_master_bus_init(struct i3c_master_controller *m)
> +{
> +	struct cdns_i3c_master *master = to_cdns_i3c_master(m);
> +	unsigned long pres_step, sysclk_rate, max_i2cfreq;
> +	u32 ctrl, prescl0, prescl1, pres, low;
> +	struct i3c_device_info info = { };
> +	struct i3c_ccc_events events;
> +	struct i2c_device *i2cdev;
> +	struct i3c_device *i3cdev;
> +	int ret, slot, ncycles;
> +	u8 last_addr = 0;
> +
> +	switch (m->bus->mode) {
> +	case I3C_BUS_MODE_PURE:
> +		ctrl = CTRL_PURE_BUS_MODE;
> +		break;
> +
> +	case I3C_BUS_MODE_MIXED_FAST:
> +		ctrl = CTRL_MIXED_FAST_BUS_MODE;
> +		break;
> +
> +	case I3C_BUS_MODE_MIXED_SLOW:
> +		ctrl = CTRL_MIXED_SLOW_BUS_MODE;
> +		break;
> +
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	sysclk_rate = clk_get_rate(master->sysclk);
> +	if (!sysclk_rate)
> +		return -EINVAL;
> +
> +	pres = DIV_ROUND_UP(sysclk_rate, (m->bus->scl_rate.i3c * 4)) - 1;
> +	if (pres > PRESCL_CTRL0_MAX)
> +		return -ERANGE;
> +
> +	m->bus->scl_rate.i3c = sysclk_rate / ((pres + 1) * 4);
> +
> +	prescl0 = PRESCL_CTRL0_I3C(pres);
> +
> +	low = ((I3C_BUS_TLOW_OD_MIN_NS * sysclk_rate) / (pres + 1)) - 2;
> +	prescl1 = PRESCL_CTRL1_OD_LOW(low);
> +
> +	max_i2cfreq = m->bus->scl_rate.i2c;
> +
> +	pres = (sysclk_rate / (max_i2cfreq * 5)) - 1;
> +	if (pres > PRESCL_CTRL0_MAX)
> +		return -ERANGE;
> +
> +	m->bus->scl_rate.i2c = sysclk_rate / ((pres + 1) * 5);
> +
> +	prescl0 |= PRESCL_CTRL0_I2C(pres);
> +
> +	writel(DEVS_CTRL_DEV_CLR_ALL, master->regs + DEVS_CTRL);
> +
> +	i3c_bus_for_each_i2cdev(m->bus, i2cdev) {
> +		ret = cdns_i3c_master_attach_i2c_dev(master, i2cdev);
> +		if (ret)
> +			goto err_detach_devs;
> +	}
> +
> +	writel(prescl0, master->regs + PRESCL_CTRL0);
> +
> +	/* Calculate OD and PP low. */
> +	pres_step = 1000000000 / (m->bus->scl_rate.i3c * 4);
> +	ncycles = DIV_ROUND_UP(I3C_BUS_TLOW_OD_MIN_NS, pres_step) - 2;
> +	if (ncycles < 0)
> +		ncycles = 0;
> +	prescl1 = PRESCL_CTRL1_OD_LOW(ncycles);
> +	writel(prescl1, master->regs + PRESCL_CTRL1);
> +
> +	i3c_bus_for_each_i3cdev(m->bus, i3cdev) {
> +		ret = cdns_i3c_master_attach_i3c_dev(master, i3cdev);
> +		if (ret)
> +			goto err_detach_devs;
> +	}
> +
> +	/* Get an address for the master. */
> +	ret = i3c_master_get_free_addr(m, 0);
> +	if (ret < 0)
> +		goto err_detach_devs;
> +
> +	writel(prepare_rr0_dev_address(ret) | DEV_ID_RR0_IS_I3C,
> +	       master->regs + DEV_ID_RR0(0));
> +
> +	cdns_i3c_master_dev_rr_to_info(master, 0, &info);
> +	if (info.bcr & I3C_BCR_HDR_CAP)
> +		info.hdr_cap = I3C_CCC_HDR_MODE(I3C_HDR_DDR);
> +
> +	ret = i3c_master_set_info(&master->base, &info);
> +	if (ret)
> +		goto err_detach_devs;
> +
> +	/* Prepare RR slots before lauching DAA. */

	                           launching

> +	for (slot = find_next_bit(&master->free_dev_slots, BITS_PER_LONG, 1);
> +	     slot < BITS_PER_LONG;
> +	     slot = find_next_bit(&master->free_dev_slots,
> +				  BITS_PER_LONG, slot + 1)) {
> +		ret = i3c_master_get_free_addr(m, last_addr + 1);
> +		if (ret < 0)
> +			goto err_disable_master;
> +
> +		last_addr = ret;
> +		writel(prepare_rr0_dev_address(last_addr) | DEV_ID_RR0_IS_I3C,
> +		       master->regs + DEV_ID_RR0(slot));
> +		writel(0, master->regs + DEV_ID_RR1(slot));
> +		writel(0, master->regs + DEV_ID_RR2(slot));
> +	}
> +
> +	/*
> +	 * Enable Hot-Join and when a Hot-Join request happen, disable all

	                                               happens,

> +	 * events coming from this device.
> +	 *
> +	 * We will issue ENTDAA afterwards from the threaded IRQ handler.
> +	 */
> +	ctrl |= CTRL_HJ_ACK | CTRL_HJ_DISEC | CTRL_HALT_EN;
> +	writel(ctrl, master->regs + CTRL);
> +
> +	cdns_i3c_master_enable(master);
> +
> +	/*
> +	 * Reset all dynamic addresses on the bus, because we don't know what
> +	 * happened before this point (the bootloader may have assigned dynamic
> +	 * addresses that we're not aware of).
> +	 */
> +	ret = i3c_master_rstdaa_locked(m, I3C_BROADCAST_ADDR);
> +	if (ret)
> +		goto err_disable_master;
> +
> +	/* Disable all slave events (interrupts) before starting DAA. */
> +	events.events = I3C_CCC_EVENT_SIR | I3C_CCC_EVENT_MR |
> +			I3C_CCC_EVENT_HJ;
> +	ret = i3c_master_disec_locked(m, I3C_BROADCAST_ADDR, &events);
> +	if (ret)
> +		goto err_disable_master;
> +
> +	ret = cdns_i3c_master_do_daa_locked(master);
> +	if (ret < 0)
> +		goto err_disable_master;
> +
> +	/* Unmask Hot-Join and Marstership request interrupts. */

	Is that                Mastership ?

> +	events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR;
> +	ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, &events);
> +	if (ret)
> +		pr_info("Failed to re-enable H-J");

		Not very good info...

> +
> +	writel(MST_INT_HJ_REQ, master->regs + MST_IER);
> +	return 0;
> +
> +err_disable_master:
> +	cdns_i3c_master_disable(master);
> +
> +err_detach_devs:
> +	cdns_i3c_master_bus_cleanup(m);
> +
> +	return ret;
> +}
> +

[snip]


-- 
~Randy

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 6/7] i3c: master: Add driver for Cadence IP
  2017-12-14 19:54   ` Randy Dunlap
@ 2017-12-14 20:17     ` Boris Brezillon
  2017-12-14 20:25       ` Randy Dunlap
  0 siblings, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2017-12-14 20:17 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Vitor Soares, Geert Uytterhoeven, Linus Walleij

Hi Randy,

On Thu, 14 Dec 2017 11:54:16 -0800
Randy Dunlap <rdunlap@infradead.org> wrote:

> On 12/14/2017 07:16 AM, Boris Brezillon wrote:
> > Add a driver for Cadence I3C master IP.
> > 
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > ---
> > Changes in v2:
> > - Add basic IBI support. Note that the IP is not really reliable with
> >   regards to IBI because you can't extract IBI payloads as soon as you
> >   have more than one IBI waiting in the HW queue. This is something
> >   that will hopefully be addressed in future revisions of this IP
> > - Add a simple xfer queueing mechanism to optimize message queuing.
> > - Fix a few bugs
> > - Add support for Hot Join
> > ---
> >  drivers/i3c/master/Kconfig           |    5 +
> >  drivers/i3c/master/Makefile          |    1 +
> >  drivers/i3c/master/i3c-master-cdns.c | 1797 ++++++++++++++++++++++++++++++++++
> >  3 files changed, 1803 insertions(+)
> >  create mode 100644 drivers/i3c/master/i3c-master-cdns.c
> > 
> > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
> > index e69de29bb2d1..56b9a18543b2 100644
> > --- a/drivers/i3c/master/Kconfig
> > +++ b/drivers/i3c/master/Kconfig
> > @@ -0,0 +1,5 @@
> > +config CDNS_I3C_MASTER
> > +	tristate "Cadence I3C master driver"
> > +	depends on I3C
> > +	help
> > +	  Enable this driver if you want to support Cadence I3C master block.
> > diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
> > index e69de29bb2d1..4c4304aa9534 100644
> > --- a/drivers/i3c/master/Makefile
> > +++ b/drivers/i3c/master/Makefile
> > @@ -0,0 +1 @@
> > +obj-$(CONFIG_CDNS_I3C_MASTER)		+= i3c-master-cdns.o
> > diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c
> > new file mode 100644
> > index 000000000000..3e3ef37c01c2
> > --- /dev/null
> > +++ b/drivers/i3c/master/i3c-master-cdns.c
> > @@ -0,0 +1,1797 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> > + */
> > +  
> 
> Rule #1 from submit-checklist.rst:
> 1) If you use a facility then #include the file that defines/declares
>    that facility.  Don't depend on other header files pulling in ones
>    that you use.
> 
> 
> #include <linux/bitops.h>
> for BIT(x) and hweight8() and clear_bit() and find_next_bit()
> and hweight32()
> 
> > +#include <linux/clk.h>  
> 
> #include <linux/err.h>
> for IS_ERR(), PTR_ERR()
> 
> #include <linux/errno.h>
> for error codes
> 
> > +#include <linux/i3c/master.h>
> > +#include <linux/interrupt.h>  
> 
> #include <linux/io.h>
> for writel()
> 
> > +#include <linux/iopoll.h>  
> 
> #include <linux/ioport.h>
> for IORESOURCE_MEM
> 
> #include <linux/kernel.h>
> for DIV_ROUND_UP()
> 
> #include <linux/list.h>
> for list() macros and INIT_LIST_HEAD()
> 
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/slab.h>  
> 
> #include <linux/spinlock.h>
> 
> #include <linux/workqueue.h>
> for workqueue functions and INIT_WORK()

Will fix that.

> 
> > +
> > +#define DEV_ID				0x0
> > +#define DEV_ID_I3C_MASTER		0x5034  
> 
> [snip]
> 
> 
> 
> > +#define I3C_DDR_FIRST_DATA_WORD_PREAMBLE	0x2
> > +#define I3C_DDR_DATA_WORD_PREAMBLE		0x3
> > +
> > +#define I3C_DDR_PREAMBLE(p)			((p) << 18)
> > +
> > +static u32 prepare_ddr_word(u16 payload)
> > +{
> > +	u32 ret;
> > +	u16 pb;
> > +
> > +	ret = (u32)payload << 2;
> > +
> > +	/* Calculate parity. */
> > +	pb = (payload >> 15) ^ (payload >> 13) ^ (payload >> 11) ^
> > +	     (payload >> 9) ^ (payload >> 7) ^ (payload >> 5) ^
> > +	     (payload >> 3) ^ (payload >> 1);
> > +	ret |= (pb & 1) << 1;
> > +	pb = (payload >> 14) ^ (payload >> 12) ^ (payload >> 10) ^
> > +	     (payload >> 8) ^ (payload >> 6) ^ (payload >> 4) ^
> > +	     (payload >> 2) ^ payload ^ 1;
> > +	ret |= (pb & 1);
> > +
> > +	return ret;
> > +}
> > +
> > +static u32 prepare_ddr_data_word(u16 data, bool first)
> > +{
> > +	return prepare_ddr_word(data) | I3C_DDR_PREAMBLE(first ? 2 : 3);  
> 
> Just defined macros for 2 & 3 above. Use them instead of magic numbers?

Oops, that was my intention, just forgot to use the macros I had
defined.

> 
> > +}
> > +
> > +#define I3C_DDR_READ_CMD	BIT(15)
> > +
> > +static u32 prepare_ddr_cmd_word(u16 cmd)
> > +{
> > +	return prepare_ddr_word(cmd) | I3C_DDR_PREAMBLE(1);
> > +}
> > +
> > +static u32 prepare_ddr_crc_word(u8 crc5)
> > +{
> > +	return (((u32)crc5 & 0x1f) << 9) | (0xc << 14) |
> > +	       I3C_DDR_PREAMBLE(1);
> > +}
> > +
> > +static u8 update_crc5(u8 crc5, u16 word)
> > +{
> > +	u8 crc0;
> > +	int i;
> > +
> > +	/*
> > +	 * crc0 = next_data_bit ^ crc[4]
> > +	 *                1         2            3       4
> > +	 * crc[4:0] = { crc[3:2], crc[1]^crc0, crc[0], crc0 }
> > +	 */
> > +	for (i = 0; i < 16; ++i) {
> > +		crc0 = ((word >> (15 - i)) ^ (crc5 >> 4)) & 0x1;
> > +		crc5 = ((crc5 << 1) & (0x18 | 0x2)) |
> > +		       (((crc5 >> 1) ^ crc0) << 2) | crc0;
> > +	}
> > +
> > +	return crc5 & 0x1F;
> > +}
> > +  
> 
> [snip]
> 
> 
> 
> > +static int cdns_i3c_master_do_daa_locked(struct cdns_i3c_master *master)
> > +{
> > +	unsigned long i3c_lim_period, pres_step, i3c_scl_lim;
> > +	struct i3c_device_info devinfo;
> > +	struct i3c_device *i3cdev;
> > +	u32 prescl1, ctrl, devs;
> > +	int ret, slot, ncycles;
> > +
> > +	ret = i3c_master_entdaa_locked(&master->base);
> > +	if (ret)
> > +		return ret;
> > +
> > +	/* Now, add discovered devices to the bus. */
> > +	i3c_scl_lim = master->i3c_scl_lim;
> > +	devs = readl(master->regs + DEVS_CTRL);
> > +	for (slot = find_next_bit(&master->free_dev_slots, BITS_PER_LONG, 1);
> > +	     slot < BITS_PER_LONG;
> > +	     slot = find_next_bit(&master->free_dev_slots,
> > +				  BITS_PER_LONG, slot + 1)) {
> > +		struct cdns_i3c_i2c_dev_data *data;
> > +		u32 rr, max_fscl = 0;
> > +		u8 addr;
> > +
> > +		if (!(devs & DEVS_CTRL_DEV_ACTIVE(slot)))
> > +			continue;
> > +
> > +		data = kzalloc(sizeof(*data), GFP_KERNEL);
> > +		if (!data)
> > +			return -ENOMEM;
> > +
> > +		data->ibi = -1;
> > +		data->id = slot;
> > +		rr = readl(master->regs + DEV_ID_RR0(slot));
> > +		addr = DEV_ID_RR0_GET_DEV_ADDR(rr);
> > +		i3cdev = i3c_master_add_i3c_dev_locked(&master->base, addr);
> > +		if (IS_ERR(i3cdev))
> > +			return PTR_ERR(i3cdev);
> > +
> > +		i3c_device_get_info(i3cdev, &devinfo);
> > +		clear_bit(data->id, &master->free_dev_slots);
> > +		i3c_device_set_master_data(i3cdev, data);
> > +
> > +		max_fscl = max(I3C_CCC_MAX_SDR_FSCL(devinfo.max_read_ds),
> > +			       I3C_CCC_MAX_SDR_FSCL(devinfo.max_write_ds));
> > +		switch (max_fscl) {
> > +		case I3C_SDR_DR_FSCL_8MHZ:
> > +			max_fscl = 8000000;
> > +			break;
> > +		case I3C_SDR_DR_FSCL_6MHZ:
> > +			max_fscl = 6000000;
> > +			break;
> > +		case I3C_SDR_DR_FSCL_4MHZ:
> > +			max_fscl = 4000000;
> > +			break;
> > +		case I3C_SDR_DR_FSCL_2MHZ:
> > +			max_fscl = 2000000;
> > +			break;
> > +		case I3C_SDR_DR_FSCL_MAX:
> > +		default:
> > +			max_fscl = 0;
> > +			break;
> > +		}
> > +
> > +		if (max_fscl && (max_fscl < i3c_scl_lim || !i3c_scl_lim))
> > +			i3c_scl_lim = max_fscl;
> > +	}
> > +
> > +	i3c_master_defslvs_locked(&master->base);
> > +
> > +	pres_step = 1000000000 / (master->base.bus->scl_rate.i3c * 4);  
> 
> Does that build OK on 32-bit target arch?

It's a 32 bit integer divided by another 32 bit integer, and yes, I
tested it on a 32  platform. This being said, I should use NSEC_PER_SEC
instead of 1000000000.

> 
> > +
> > +	/* No bus limitation to apply, bail out. */
> > +	if (!i3c_scl_lim ||
> > +	    (master->i3c_scl_lim && master->i3c_scl_lim <= i3c_scl_lim))
> > +		return 0;
> > +
> > +	/* Configure PP_LOW to meet I3C slave limitations. */
> > +	prescl1 = readl(master->regs + PRESCL_CTRL1) &
> > +		  ~PRESCL_CTRL1_PP_LOW_MASK;
> > +	ctrl = readl(master->regs + CTRL) & ~CTRL_DEV_EN;
> > +
> > +	i3c_lim_period = DIV_ROUND_UP(1000000000, i3c_scl_lim);
> > +	ncycles = DIV_ROUND_UP(i3c_lim_period, pres_step) - 4;
> > +	if (ncycles < 0)
> > +		ncycles = 0;
> > +	prescl1 |= PRESCL_CTRL1_PP_LOW(ncycles);
> > +
> > +	/* Disable I3C master before updating PRESCL_CTRL1. */
> > +	ret = cdns_i3c_master_disable(master);
> > +	if (!ret) {
> > +		writel(prescl1, master->regs + PRESCL_CTRL1);
> > +		master->i3c_scl_lim = i3c_scl_lim;
> > +	}
> > +	cdns_i3c_master_enable(master);
> > +
> > +	return ret;
> > +}
> > +
> > +static int cdns_i3c_master_bus_init(struct i3c_master_controller *m)
> > +{
> > +	struct cdns_i3c_master *master = to_cdns_i3c_master(m);
> > +	unsigned long pres_step, sysclk_rate, max_i2cfreq;
> > +	u32 ctrl, prescl0, prescl1, pres, low;
> > +	struct i3c_device_info info = { };
> > +	struct i3c_ccc_events events;
> > +	struct i2c_device *i2cdev;
> > +	struct i3c_device *i3cdev;
> > +	int ret, slot, ncycles;
> > +	u8 last_addr = 0;
> > +
> > +	switch (m->bus->mode) {
> > +	case I3C_BUS_MODE_PURE:
> > +		ctrl = CTRL_PURE_BUS_MODE;
> > +		break;
> > +
> > +	case I3C_BUS_MODE_MIXED_FAST:
> > +		ctrl = CTRL_MIXED_FAST_BUS_MODE;
> > +		break;
> > +
> > +	case I3C_BUS_MODE_MIXED_SLOW:
> > +		ctrl = CTRL_MIXED_SLOW_BUS_MODE;
> > +		break;
> > +
> > +	default:
> > +		return -EINVAL;
> > +	}
> > +
> > +	sysclk_rate = clk_get_rate(master->sysclk);
> > +	if (!sysclk_rate)
> > +		return -EINVAL;
> > +
> > +	pres = DIV_ROUND_UP(sysclk_rate, (m->bus->scl_rate.i3c * 4)) - 1;
> > +	if (pres > PRESCL_CTRL0_MAX)
> > +		return -ERANGE;
> > +
> > +	m->bus->scl_rate.i3c = sysclk_rate / ((pres + 1) * 4);
> > +
> > +	prescl0 = PRESCL_CTRL0_I3C(pres);
> > +
> > +	low = ((I3C_BUS_TLOW_OD_MIN_NS * sysclk_rate) / (pres + 1)) - 2;
> > +	prescl1 = PRESCL_CTRL1_OD_LOW(low);
> > +
> > +	max_i2cfreq = m->bus->scl_rate.i2c;
> > +
> > +	pres = (sysclk_rate / (max_i2cfreq * 5)) - 1;
> > +	if (pres > PRESCL_CTRL0_MAX)
> > +		return -ERANGE;
> > +
> > +	m->bus->scl_rate.i2c = sysclk_rate / ((pres + 1) * 5);
> > +
> > +	prescl0 |= PRESCL_CTRL0_I2C(pres);
> > +
> > +	writel(DEVS_CTRL_DEV_CLR_ALL, master->regs + DEVS_CTRL);
> > +
> > +	i3c_bus_for_each_i2cdev(m->bus, i2cdev) {
> > +		ret = cdns_i3c_master_attach_i2c_dev(master, i2cdev);
> > +		if (ret)
> > +			goto err_detach_devs;
> > +	}
> > +
> > +	writel(prescl0, master->regs + PRESCL_CTRL0);
> > +
> > +	/* Calculate OD and PP low. */
> > +	pres_step = 1000000000 / (m->bus->scl_rate.i3c * 4);
> > +	ncycles = DIV_ROUND_UP(I3C_BUS_TLOW_OD_MIN_NS, pres_step) - 2;
> > +	if (ncycles < 0)
> > +		ncycles = 0;
> > +	prescl1 = PRESCL_CTRL1_OD_LOW(ncycles);
> > +	writel(prescl1, master->regs + PRESCL_CTRL1);
> > +
> > +	i3c_bus_for_each_i3cdev(m->bus, i3cdev) {
> > +		ret = cdns_i3c_master_attach_i3c_dev(master, i3cdev);
> > +		if (ret)
> > +			goto err_detach_devs;
> > +	}
> > +
> > +	/* Get an address for the master. */
> > +	ret = i3c_master_get_free_addr(m, 0);
> > +	if (ret < 0)
> > +		goto err_detach_devs;
> > +
> > +	writel(prepare_rr0_dev_address(ret) | DEV_ID_RR0_IS_I3C,
> > +	       master->regs + DEV_ID_RR0(0));
> > +
> > +	cdns_i3c_master_dev_rr_to_info(master, 0, &info);
> > +	if (info.bcr & I3C_BCR_HDR_CAP)
> > +		info.hdr_cap = I3C_CCC_HDR_MODE(I3C_HDR_DDR);
> > +
> > +	ret = i3c_master_set_info(&master->base, &info);
> > +	if (ret)
> > +		goto err_detach_devs;
> > +
> > +	/* Prepare RR slots before lauching DAA. */  
> 
> 	                           launching
> 
> > +	for (slot = find_next_bit(&master->free_dev_slots, BITS_PER_LONG, 1);
> > +	     slot < BITS_PER_LONG;
> > +	     slot = find_next_bit(&master->free_dev_slots,
> > +				  BITS_PER_LONG, slot + 1)) {
> > +		ret = i3c_master_get_free_addr(m, last_addr + 1);
> > +		if (ret < 0)
> > +			goto err_disable_master;
> > +
> > +		last_addr = ret;
> > +		writel(prepare_rr0_dev_address(last_addr) | DEV_ID_RR0_IS_I3C,
> > +		       master->regs + DEV_ID_RR0(slot));
> > +		writel(0, master->regs + DEV_ID_RR1(slot));
> > +		writel(0, master->regs + DEV_ID_RR2(slot));
> > +	}
> > +
> > +	/*
> > +	 * Enable Hot-Join and when a Hot-Join request happen, disable all  
> 
> 	                                               happens,
> 
> > +	 * events coming from this device.
> > +	 *
> > +	 * We will issue ENTDAA afterwards from the threaded IRQ handler.
> > +	 */
> > +	ctrl |= CTRL_HJ_ACK | CTRL_HJ_DISEC | CTRL_HALT_EN;
> > +	writel(ctrl, master->regs + CTRL);
> > +
> > +	cdns_i3c_master_enable(master);
> > +
> > +	/*
> > +	 * Reset all dynamic addresses on the bus, because we don't know what
> > +	 * happened before this point (the bootloader may have assigned dynamic
> > +	 * addresses that we're not aware of).
> > +	 */
> > +	ret = i3c_master_rstdaa_locked(m, I3C_BROADCAST_ADDR);
> > +	if (ret)
> > +		goto err_disable_master;
> > +
> > +	/* Disable all slave events (interrupts) before starting DAA. */
> > +	events.events = I3C_CCC_EVENT_SIR | I3C_CCC_EVENT_MR |
> > +			I3C_CCC_EVENT_HJ;
> > +	ret = i3c_master_disec_locked(m, I3C_BROADCAST_ADDR, &events);
> > +	if (ret)
> > +		goto err_disable_master;
> > +
> > +	ret = cdns_i3c_master_do_daa_locked(master);
> > +	if (ret < 0)
> > +		goto err_disable_master;
> > +
> > +	/* Unmask Hot-Join and Marstership request interrupts. */  
> 
> 	Is that                Mastership ?

It is. I'll fix the other typos you pointed.

> 
> > +	events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR;
> > +	ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, &events);
> > +	if (ret)
> > +		pr_info("Failed to re-enable H-J");  
> 
> 		Not very good info...

What do you mean? Is it the H-J that bothers you (I can replace it by
'Hot-Join'), or is it something else?

Thanks for the review.

Boris

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 6/7] i3c: master: Add driver for Cadence IP
  2017-12-14 20:17     ` Boris Brezillon
@ 2017-12-14 20:25       ` Randy Dunlap
  2017-12-14 20:44         ` Boris Brezillon
  0 siblings, 1 reply; 50+ messages in thread
From: Randy Dunlap @ 2017-12-14 20:25 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Vitor Soares, Geert Uytterhoeven, Linus Walleij

On 12/14/2017 12:17 PM, Boris Brezillon wrote:
>>> +	events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR;
>>> +	ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, &events);
>>> +	if (ret)
>>> +		pr_info("Failed to re-enable H-J");  
>> 		Not very good info...
> What do you mean? Is it the H-J that bothers you (I can replace it by
> 'Hot-Join'), or is it something else?

Who is the message for?  If it's for developers, you could use
pr_debug().  If it's for users, it needs more clarity.

Does it print the source of the message? (module name e.g.)
and yes, Hot-Join would be better IMO.

-- 
~Randy

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 6/7] i3c: master: Add driver for Cadence IP
  2017-12-14 20:25       ` Randy Dunlap
@ 2017-12-14 20:44         ` Boris Brezillon
  2017-12-14 22:10           ` Randy Dunlap
  0 siblings, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2017-12-14 20:44 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Vitor Soares, Geert Uytterhoeven, Linus Walleij

On Thu, 14 Dec 2017 12:25:14 -0800
Randy Dunlap <rdunlap@infradead.org> wrote:

> On 12/14/2017 12:17 PM, Boris Brezillon wrote:
> >>> +	events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR;
> >>> +	ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, &events);
> >>> +	if (ret)
> >>> +		pr_info("Failed to re-enable H-J");    
> >> 		Not very good info...  
> > What do you mean? Is it the H-J that bothers you (I can replace it by
> > 'Hot-Join'), or is it something else?  
> 
> Who is the message for?  If it's for developers, you could use
> pr_debug().  If it's for users, it needs more clarity.

I think it's of interest to anyone including users. If we fail to
re-enable Hot-Join that means hotplug is no longer working which is
a bad news.

> 
> Does it print the source of the message? (module name e.g.)

I could replace it by

	dev_err(m->parent, "Failed to re-enable Hot-Join");



> and yes, Hot-Join would be better IMO.
> 

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
  2017-12-14 15:16 ` [PATCH v2 5/7] dt-bindings: i3c: Document core bindings Boris Brezillon
  2017-12-14 16:24   ` Geert Uytterhoeven
@ 2017-12-14 21:47   ` Peter Rosin
  2017-12-16 17:20   ` Rob Herring
  2 siblings, 0 replies; 50+ messages in thread
From: Peter Rosin @ 2017-12-14 21:47 UTC (permalink / raw)
  To: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij

On 2017-12-14 16:16, Boris Brezillon wrote:
> +Optional properties
> +-------------------
> +- reg: static address. Only valid is the device has a static address.
> +- i3c-dynamic-address: dynamic address to be assigned to this device. This
> +		       property depends on the reg property.
> +
> +Example:
> +
> +	i3c-master@0d040000 {

i3c-master@d040000

(same in patch 7/7)

Cheers,
Peter

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 6/7] i3c: master: Add driver for Cadence IP
  2017-12-14 20:44         ` Boris Brezillon
@ 2017-12-14 22:10           ` Randy Dunlap
  0 siblings, 0 replies; 50+ messages in thread
From: Randy Dunlap @ 2017-12-14 22:10 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Vitor Soares, Geert Uytterhoeven, Linus Walleij

On 12/14/2017 12:44 PM, Boris Brezillon wrote:
> On Thu, 14 Dec 2017 12:25:14 -0800
> Randy Dunlap <rdunlap@infradead.org> wrote:
> 
>> On 12/14/2017 12:17 PM, Boris Brezillon wrote:
>>>>> +	events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR;
>>>>> +	ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, &events);
>>>>> +	if (ret)
>>>>> +		pr_info("Failed to re-enable H-J");    
>>>> 		Not very good info...  
>>> What do you mean? Is it the H-J that bothers you (I can replace it by
>>> 'Hot-Join'), or is it something else?  
>>
>> Who is the message for?  If it's for developers, you could use
>> pr_debug().  If it's for users, it needs more clarity.
> 
> I think it's of interest to anyone including users. If we fail to
> re-enable Hot-Join that means hotplug is no longer working which is
> a bad news.
> 
>>
>> Does it print the source of the message? (module name e.g.)
> 
> I could replace it by
> 
> 	dev_err(m->parent, "Failed to re-enable Hot-Join");
> 

Yes, that's a good plan.

Thanks.

> 
> 
>> and yes, Hot-Join would be better IMO.


-- 
~Randy

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
  2017-12-14 15:16 ` [PATCH v2 5/7] dt-bindings: i3c: Document core bindings Boris Brezillon
  2017-12-14 16:24   ` Geert Uytterhoeven
  2017-12-14 21:47   ` Peter Rosin
@ 2017-12-16 17:20   ` Rob Herring
  2017-12-16 18:35     ` Boris Brezillon
  2 siblings, 1 reply; 50+ messages in thread
From: Rob Herring @ 2017-12-16 17:20 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
	Geert Uytterhoeven, Linus Walleij

On Thu, Dec 14, 2017 at 04:16:08PM +0100, Boris Brezillon wrote:
> A new I3C subsystem has been added and a generic description has been
> created to represent the I3C bus and the devices connected on it.
> 
> Document this generic representation.
> 
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Changes in v2:
> - Define how to describe I3C devices in the DT and when it should be
>   used. Note that the parsing of I3C devices is not yet implemented in
>   the framework. Will be added when someone really needs it.
> ---
>  Documentation/devicetree/bindings/i3c/i3c.txt | 128 ++++++++++++++++++++++++++
>  1 file changed, 128 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
> 
> diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt b/Documentation/devicetree/bindings/i3c/i3c.txt
> new file mode 100644
> index 000000000000..79a214dee025
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> @@ -0,0 +1,128 @@
> +Generic device tree bindings for I3C busses
> +===========================================
> +
> +This document describes generic bindings that should be used to describe I3C
> +busses in a device tree.
> +
> +Required properties
> +-------------------
> +
> +- #address-cells  - should be <1>. Read more about addresses below.
> +- #size-cells     - should be <0>.
> +- compatible      - name of I3C bus controller following generic names
> +		    recommended practice.

generic names isn't anything recommended.

One problem we have with i2c buses is we can't identify them in the DT 
other than with a list of all controller's compatible strings. We can 
fix this by defining the controller node name. So please define the node 
name to be "i3c-controller". That's more inline with other node names 
than i3c-master that you used below.

> +
> +For other required properties e.g. to describe register sets,
> +clocks, etc. check the binding documentation of the specific driver.
> +
> +Optional properties
> +-------------------
> +
> +These properties may not be supported by all I3C master drivers. Each I3C
> +master bindings should specify which of them are supported.
> +
> +- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
> +		     transfers. When undefined the core set it to 12.5MHz.
> +
> +- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
> +		     transfers. When undefined, the core looks at LVR values
> +		     of I2C devices described in the device tree to determine
> +		     the maximum I2C frequency.

Add '-hz' suffix. You could drop 'frequency' as that would be implied by 
Hz.

> +
> +I2C devices
> +===========
> +
> +Each I2C device connected to the bus should be described in a subnode with
> +the following properties:
> +
> +All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
> +valid here.
> +
> +New required properties:
> +------------------------
> +- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
> +	   describing device capabilities as described in the I3C
> +	   specification.
> +
> +	   bit[31:8]: unused
> +	   bit[7:5]: I2C device index. Possible values
> +	    * 0: I2C device has a 50 ns spike filter
> +	    * 1: I2C device does not have a 50 ns spike filter but supports high
> +		 frequency on SCL
> +	    * 2: I2C device does not have a 50 ns spike filter and is not
> +		 tolerant to high frequencies
> +	    * 3-7: reserved
> +
> +	   bit[4]: tell whether the device operates in FM or FM+ mode
> +	    * 0: FM+ mode
> +	    * 1: FM mode
> +
> +	   bit[3:0]: device type
> +	    * 0-15: reserved
> +
> +I3C devices
> +===========
> +
> +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
> +are thus discoverable. So, by default, I3C devices do not have to be described
> +in the device tree.
> +This being said, one might want to attach extra resources to these devices,
> +and those resources may have to be described in the device tree, which in turn
> +means we have to describe I3C devices.
> +
> +Another use case for describing an I3C device in the device tree is when this
> +I3C device has a static address and we want to assign it a specific dynamic
> +address before the DAA takes place (so that other devices on the bus can't
> +take this dynamic address).
> +
> +Required properties
> +-------------------
> +- i3c-pid: PID (Provisional ID). 64-bit property which is used to match a
> +	   device discovered during DAA with its device tree definition. The
> +	   PID is supposed to be unique on a given bus, which guarantees a 1:1
> +	   match. This property becomes optional if a reg property is defined,
> +	   meaning that the device has a static address.

What determines this number?

> +
> +Optional properties
> +-------------------
> +- reg: static address. Only valid is the device has a static address.
> +- i3c-dynamic-address: dynamic address to be assigned to this device. This
> +		       property depends on the reg property.

Perhaps "assigned-address" property would be appropriate. I'm not all 
that familiar with it though.

> +
> +Example:
> +
> +	i3c-master@0d040000 {

Drop leading 0.

> +		compatible = "cdns,i3c-master";
> +		clocks = <&coreclock>, <&i3csysclock>;
> +		clock-names = "pclk", "sysclk";
> +		interrupts = <3 0>;
> +		reg = <0x0d040000 0x1000>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		status = "okay";
> +		i2c-scl-frequency = <100000>;
> +
> +		/* I2C device. */
> +		nunchuk: nunchuk@52 {
> +			compatible = "nintendo,nunchuk";
> +			reg = <0x52>;
> +			i3c-lvr = <0x10>;
> +		};
> +
> +		/* I3C device with a static address. */
> +		thermal_sensor: sensor@68 {
> +			reg = <0x68>;
> +			i3c-dynamic-address = <0xa>;
> +		};
> +
> +		/*
> +		 * I3C device without a static address but requiring resources
> +		 * described in the DT.
> +		 */
> +		sensor2 {

It's not great that we can't follow using generic node names. Maybe the 
PID can be used as the address? In USB for example, we use hub ports for 
DT addresses rather than USB addresses since those are dynamic.

> +			i3c-pid = /bits/ 64 <0x39200144004>;
> +			clocks = <&clock_provider 0>;
> +		};
> +	};
> +
> -- 
> 2.11.0
> 

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
  2017-12-16 17:20   ` Rob Herring
@ 2017-12-16 18:35     ` Boris Brezillon
  2017-12-20 18:06       ` Rob Herring
  0 siblings, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2017-12-16 18:35 UTC (permalink / raw)
  To: Rob Herring
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
	Geert Uytterhoeven, Linus Walleij

On Sat, 16 Dec 2017 11:20:40 -0600
Rob Herring <robh@kernel.org> wrote:

> On Thu, Dec 14, 2017 at 04:16:08PM +0100, Boris Brezillon wrote:
> > A new I3C subsystem has been added and a generic description has been
> > created to represent the I3C bus and the devices connected on it.
> > 
> > Document this generic representation.
> > 
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > ---
> > Changes in v2:
> > - Define how to describe I3C devices in the DT and when it should be
> >   used. Note that the parsing of I3C devices is not yet implemented in
> >   the framework. Will be added when someone really needs it.
> > ---
> >  Documentation/devicetree/bindings/i3c/i3c.txt | 128 ++++++++++++++++++++++++++
> >  1 file changed, 128 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt b/Documentation/devicetree/bindings/i3c/i3c.txt
> > new file mode 100644
> > index 000000000000..79a214dee025
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> > @@ -0,0 +1,128 @@
> > +Generic device tree bindings for I3C busses
> > +===========================================
> > +
> > +This document describes generic bindings that should be used to describe I3C
> > +busses in a device tree.
> > +
> > +Required properties
> > +-------------------
> > +
> > +- #address-cells  - should be <1>. Read more about addresses below.
> > +- #size-cells     - should be <0>.
> > +- compatible      - name of I3C bus controller following generic names
> > +		    recommended practice.  
> 
> generic names isn't anything recommended.

Hm, I agree. Don't even know what I wanted to say (it's probably been
copied from somewhere else).

> 
> One problem we have with i2c buses is we can't identify them in the DT 
> other than with a list of all controller's compatible strings. We can 
> fix this by defining the controller node name.

I'm fine with that.

> So please define the node 
> name to be "i3c-controller". That's more inline with other node names 
> than i3c-master that you used below.

Hm, not sure i3c-controller is appropriate though, because you can have
slave controllers. Maybe i3c-host, but I'd prefer to keep the term
master since it's employed everywhere in the spec. I can also be
i3c-master-controller if you prefer.

> 
> > +
> > +For other required properties e.g. to describe register sets,
> > +clocks, etc. check the binding documentation of the specific driver.
> > +
> > +Optional properties
> > +-------------------
> > +
> > +These properties may not be supported by all I3C master drivers. Each I3C
> > +master bindings should specify which of them are supported.
> > +
> > +- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
> > +		     transfers. When undefined the core set it to 12.5MHz.
> > +
> > +- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
> > +		     transfers. When undefined, the core looks at LVR values
> > +		     of I2C devices described in the device tree to determine
> > +		     the maximum I2C frequency.  
> 
> Add '-hz' suffix. You could drop 'frequency' as that would be implied by 
> Hz.

Okay.

> 
> > +
> > +I2C devices
> > +===========
> > +
> > +Each I2C device connected to the bus should be described in a subnode with
> > +the following properties:
> > +
> > +All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
> > +valid here.
> > +
> > +New required properties:
> > +------------------------
> > +- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
> > +	   describing device capabilities as described in the I3C
> > +	   specification.
> > +
> > +	   bit[31:8]: unused
> > +	   bit[7:5]: I2C device index. Possible values
> > +	    * 0: I2C device has a 50 ns spike filter
> > +	    * 1: I2C device does not have a 50 ns spike filter but supports high
> > +		 frequency on SCL
> > +	    * 2: I2C device does not have a 50 ns spike filter and is not
> > +		 tolerant to high frequencies
> > +	    * 3-7: reserved
> > +
> > +	   bit[4]: tell whether the device operates in FM or FM+ mode
> > +	    * 0: FM+ mode
> > +	    * 1: FM mode
> > +
> > +	   bit[3:0]: device type
> > +	    * 0-15: reserved
> > +
> > +I3C devices
> > +===========
> > +
> > +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
> > +are thus discoverable. So, by default, I3C devices do not have to be described
> > +in the device tree.
> > +This being said, one might want to attach extra resources to these devices,
> > +and those resources may have to be described in the device tree, which in turn
> > +means we have to describe I3C devices.
> > +
> > +Another use case for describing an I3C device in the device tree is when this
> > +I3C device has a static address and we want to assign it a specific dynamic
> > +address before the DAA takes place (so that other devices on the bus can't
> > +take this dynamic address).
> > +
> > +Required properties
> > +-------------------
> > +- i3c-pid: PID (Provisional ID). 64-bit property which is used to match a
> > +	   device discovered during DAA with its device tree definition. The
> > +	   PID is supposed to be unique on a given bus, which guarantees a 1:1
> > +	   match. This property becomes optional if a reg property is defined,
> > +	   meaning that the device has a static address.  
> 
> What determines this number?

Part of it is fixed (manufacturer and part id) and the last few bits
represent the device instance on the bus (so you can have several
identical devices on the same bus). The manufacturer and part ids
should be statically assigned during production, instance id is usually
configurable through extra pins that you drive high or low at reset
time.

> 
> > +
> > +Optional properties
> > +-------------------
> > +- reg: static address. Only valid is the device has a static address.
> > +- i3c-dynamic-address: dynamic address to be assigned to this device. This
> > +		       property depends on the reg property.  
> 
> Perhaps "assigned-address" property would be appropriate. I'm not all 
> that familiar with it though.

Again, the spec use the term "dynamic address" everywhere, and I'd like
to stay as close as possible to the spec.

> 
> > +
> > +Example:
> > +
> > +	i3c-master@0d040000 {  
> 
> Drop leading 0.

Yep, already mentioned by Peter, I'll fix that.

> 
> > +		compatible = "cdns,i3c-master";
> > +		clocks = <&coreclock>, <&i3csysclock>;
> > +		clock-names = "pclk", "sysclk";
> > +		interrupts = <3 0>;
> > +		reg = <0x0d040000 0x1000>;
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		status = "okay";
> > +		i2c-scl-frequency = <100000>;
> > +
> > +		/* I2C device. */
> > +		nunchuk: nunchuk@52 {
> > +			compatible = "nintendo,nunchuk";
> > +			reg = <0x52>;
> > +			i3c-lvr = <0x10>;
> > +		};
> > +
> > +		/* I3C device with a static address. */
> > +		thermal_sensor: sensor@68 {
> > +			reg = <0x68>;
> > +			i3c-dynamic-address = <0xa>;
> > +		};
> > +
> > +		/*
> > +		 * I3C device without a static address but requiring resources
> > +		 * described in the DT.
> > +		 */
> > +		sensor2 {  
> 
> It's not great that we can't follow using generic node names. Maybe the 
> PID can be used as the address? In USB for example, we use hub ports for 
> DT addresses rather than USB addresses since those are dynamic.

Hm, the problem is, we may have 2 numbering schemes here: one where reg
is used (reg representing the I2C/static address), and another one
where the PID is used.
If you're okay with mixing those 2 schemes, then I'm fine with that too.

> 
> > +			i3c-pid = /bits/ 64 <0x39200144004>;
> > +			clocks = <&clock_provider 0>;
> > +		};
> > +	};
> > +
> > -- 
> > 2.11.0
> >   

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2017-12-14 15:16 ` [PATCH v2 2/7] i3c: Add core I3C infrastructure Boris Brezillon
@ 2017-12-17 22:32   ` Randy Dunlap
  2017-12-18  8:37     ` Boris Brezillon
  2017-12-19  8:52   ` Greg Kroah-Hartman
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 50+ messages in thread
From: Randy Dunlap @ 2017-12-17 22:32 UTC (permalink / raw)
  To: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij

On 12/14/17 07:16, Boris Brezillon wrote:
> Add core infrastructure to support I3C in Linux and document it.
> 
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
>  drivers/Kconfig                 |    2 +
>  drivers/Makefile                |    2 +-
>  drivers/i3c/Kconfig             |   24 +
>  drivers/i3c/Makefile            |    4 +
>  drivers/i3c/core.c              |  573 ++++++++++++++++
>  drivers/i3c/device.c            |  344 ++++++++++
>  drivers/i3c/internals.h         |   34 +
>  drivers/i3c/master.c            | 1433 +++++++++++++++++++++++++++++++++++++++
>  drivers/i3c/master/Kconfig      |    0
>  drivers/i3c/master/Makefile     |    0
>  include/linux/i3c/ccc.h         |  380 +++++++++++
>  include/linux/i3c/device.h      |  321 +++++++++
>  include/linux/i3c/master.h      |  564 +++++++++++++++
>  include/linux/mod_devicetable.h |   17 +
>  14 files changed, 3697 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/i3c/Kconfig
>  create mode 100644 drivers/i3c/Makefile
>  create mode 100644 drivers/i3c/core.c
>  create mode 100644 drivers/i3c/device.c
>  create mode 100644 drivers/i3c/internals.h
>  create mode 100644 drivers/i3c/master.c
>  create mode 100644 drivers/i3c/master/Kconfig
>  create mode 100644 drivers/i3c/master/Makefile
>  create mode 100644 include/linux/i3c/ccc.h
>  create mode 100644 include/linux/i3c/device.h
>  create mode 100644 include/linux/i3c/master.h
> 
> diff --git a/drivers/i3c/Kconfig b/drivers/i3c/Kconfig
> new file mode 100644
> index 000000000000..cf3752412ae9
> --- /dev/null
> +++ b/drivers/i3c/Kconfig
> @@ -0,0 +1,24 @@
> +# 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 design 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

> diff --git a/drivers/i3c/core.c b/drivers/i3c/core.c
> new file mode 100644
> index 000000000000..7eb8e84acd33
> --- /dev/null
> +++ b/drivers/i3c/core.c
> @@ -0,0 +1,573 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> + */
> +
> +#include <linux/idr.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/slab.h>

#include <linux/device.h>
#include <linux/init.h>
#include <linux/list.h>
#include <linux/mutex.h>
#include <linux/rwsem.h>


> +#include "internals.h"
> +
> +static DEFINE_IDR(i3c_bus_idr);
> +static DEFINE_MUTEX(i3c_core_lock);
> +

> +/**
> + * i3c_bus_maintenance_lock - Release the bus lock after a maintenance

                          unlock

> + *			      operation
> + * @bus: I3C bus to release the lock on
> + *
> + * Should be called when the bus maintenance operation is done. See
> + * i3c_bus_maintenance_lock() for more details on what these maintenance
> + * operations are.
> + */
> +void i3c_bus_maintenance_unlock(struct i3c_bus *bus)
> +{
> +	up_write(&bus->lock);
> +}
> +EXPORT_SYMBOL_GPL(i3c_bus_maintenance_unlock);
> +

> +/**
> + * i3c_bus_normaluse_lock - Release the bus lock after a normal operation

                        unlock

> + * @bus: I3C bus to release the lock on
> + *
> + * Should be called when a normal operation is done. See
> + * i3c_bus_normaluse_lock() for more details on what these normal operations
> + * are.
> + */
> +void i3c_bus_normaluse_unlock(struct i3c_bus *bus)
> +{
> +	up_read(&bus->lock);
> +}
> +EXPORT_SYMBOL_GPL(i3c_bus_normaluse_unlock);



> +static int i3c_device_match(struct device *dev, struct device_driver *drv)

bool?

> +{
> +	struct i3c_device *i3cdev;
> +	struct i3c_driver *i3cdrv;
> +
> +	if (dev->type != &i3c_device_type)
> +		return 0;
> +
> +	i3cdev = dev_to_i3cdev(dev);
> +	i3cdrv = drv_to_i3cdrv(drv);
> +	if (i3c_device_match_id(i3cdev, i3cdrv->id_table))
> +		return 1;
> +
> +	return 0;
> +}


> diff --git a/drivers/i3c/device.c b/drivers/i3c/device.c
> new file mode 100644
> index 000000000000..dcf51150b7cb
> --- /dev/null
> +++ b/drivers/i3c/device.c
> @@ -0,0 +1,344 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> + */
> +
> +#include <linux/slab.h>

#include <linux/atomic.h>
#include <linux/bug.h>
#include <linux/completion.h>
#include <linux/device.h>
#include <linux/mutex.h>

> +#include "internals.h"



> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> new file mode 100644
> index 000000000000..1c85abac08d5
> --- /dev/null
> +++ b/drivers/i3c/master.c
> @@ -0,0 +1,1433 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> + */

#include <linux/atomic.h>
#include <linux/device.h>
#include <linux/err.h>
#include <linux/export.h>
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/of.h>

> +#include <linux/slab.h>

#include <linux/spinlock.h>
#include <linux/workqueue.h>

#include <asm-generic/bug.h>

> +#include "internals.h"


and I probably missed a few.




> diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h
> new file mode 100644
> index 000000000000..ff3e1a3e2c4c
> --- /dev/null
> +++ b/include/linux/i3c/ccc.h
> @@ -0,0 +1,380 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> + */

> +/**
> + * struct i3c_ccc_dev_desc - I3C/I3C device descriptor used for DEFSLVS

Is one of those I3C above supposed to be I2C?

> + *
> + * @dyn_addr: dynamic address assigned to the I3C slave or 0 if the entry is
> + *	      describing an I2C slave.
> + * @dcr: DCR value (not applicable to entries describing I2C devices)
> + * @lvr: LVR value (not applicable to entries describing I3C devices)
> + * @bcr: BCR value or 0 if this entry is describing an I2C slave
> + * @static_addr: static address or 0 if the device does not have a static
> + *		 address
> + *
> + * The DEFSLVS command should be passed an array of i3c_ccc_dev_desc
> + * descriptors (one entry per I3C/I2C dev controlled by the master).
> + */
> +struct i3c_ccc_dev_desc {
> +	u8 dyn_addr;
> +	union {
> +		u8 dcr;
> +		u8 lvr;
> +	};
> +	u8 bcr;
> +	u8 static_addr;
> +} __packed;


Needs bitops.h

> diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h
> new file mode 100644
> index 000000000000..83958d3a02e2
> --- /dev/null
> +++ b/include/linux/i3c/device.h
> @@ -0,0 +1,321 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> + */
> +
> +#ifndef I3C_DEV_H
> +#define I3C_DEV_H
> +
> +#include <linux/device.h>
> +#include <linux/i2c.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>


Needs bitops.h, kconfig.h.


> diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
> new file mode 100644
> index 000000000000..7ec9a4821bac
> --- /dev/null
> +++ b/include/linux/i3c/master.h
> @@ -0,0 +1,564 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> + */
> +
> +#ifndef I3C_MASTER_H
> +#define I3C_MASTER_H
> +
> +#include <linux/i2c.h>
> +#include <linux/i3c/ccc.h>
> +#include <linux/i3c/device.h>
> +#include <linux/spinlock.h>
> +
> +#define I3C_HOT_JOIN_ADDR		0x2
> +#define I3C_BROADCAST_ADDR		0x7e
> +#define I3C_MAX_ADDR			GENMASK(6, 0)
> +

Needs bitops.h, workqueue.h, rwsem.h


Needs <asm-generic/bitsperlong.h>



> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index abb6dc2ebbf8..e59da92d8ac9 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -442,6 +442,23 @@ struct pci_epf_device_id {
>  	kernel_ulong_t driver_data;
>  };
>  
> +/* i3c */
> +
> +#define I3C_MATCH_DCR			BIT(0)
> +#define I3C_MATCH_MANUF			BIT(1)
> +#define I3C_MATCH_PART			BIT(2)
> +#define I3C_MATCH_EXTRA_INFO		BIT(3)

Needs bitops.h.

> +struct i3c_device_id {
> +	__u8 match_flags;
> +	__u8 dcr;
> +	__u16 manuf_id;
> +	__u16 part_id;
> +	__u16 extra_info;
> +
> +	const void *data;
> +};
> +
>  /* spi */
>  
>  #define SPI_NAME_SIZE	32
> 


-- 
~Randy

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2017-12-17 22:32   ` Randy Dunlap
@ 2017-12-18  8:37     ` Boris Brezillon
  2017-12-18 18:22       ` Randy Dunlap
  0 siblings, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2017-12-18  8:37 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Vitor Soares, Geert Uytterhoeven, Linus Walleij

On Sun, 17 Dec 2017 14:32:04 -0800
Randy Dunlap <rdunlap@infradead.org> wrote:

> On 12/14/17 07:16, Boris Brezillon wrote:
> > Add core infrastructure to support I3C in Linux and document it.
> > 
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > ---
> >  drivers/Kconfig                 |    2 +
> >  drivers/Makefile                |    2 +-
> >  drivers/i3c/Kconfig             |   24 +
> >  drivers/i3c/Makefile            |    4 +
> >  drivers/i3c/core.c              |  573 ++++++++++++++++
> >  drivers/i3c/device.c            |  344 ++++++++++
> >  drivers/i3c/internals.h         |   34 +
> >  drivers/i3c/master.c            | 1433 +++++++++++++++++++++++++++++++++++++++
> >  drivers/i3c/master/Kconfig      |    0
> >  drivers/i3c/master/Makefile     |    0
> >  include/linux/i3c/ccc.h         |  380 +++++++++++
> >  include/linux/i3c/device.h      |  321 +++++++++
> >  include/linux/i3c/master.h      |  564 +++++++++++++++
> >  include/linux/mod_devicetable.h |   17 +
> >  14 files changed, 3697 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/i3c/Kconfig
> >  create mode 100644 drivers/i3c/Makefile
> >  create mode 100644 drivers/i3c/core.c
> >  create mode 100644 drivers/i3c/device.c
> >  create mode 100644 drivers/i3c/internals.h
> >  create mode 100644 drivers/i3c/master.c
> >  create mode 100644 drivers/i3c/master/Kconfig
> >  create mode 100644 drivers/i3c/master/Makefile
> >  create mode 100644 include/linux/i3c/ccc.h
> >  create mode 100644 include/linux/i3c/device.h
> >  create mode 100644 include/linux/i3c/master.h
> > 
> > diff --git a/drivers/i3c/Kconfig b/drivers/i3c/Kconfig
> > new file mode 100644
> > index 000000000000..cf3752412ae9
> > --- /dev/null
> > +++ b/drivers/i3c/Kconfig
> > @@ -0,0 +1,24 @@
> > +# 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 design 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  
> 
> > diff --git a/drivers/i3c/core.c b/drivers/i3c/core.c
> > new file mode 100644
> > index 000000000000..7eb8e84acd33
> > --- /dev/null
> > +++ b/drivers/i3c/core.c
> > @@ -0,0 +1,573 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> > + */
> > +
> > +#include <linux/idr.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +#include <linux/slab.h>  
> 
> #include <linux/device.h>
> #include <linux/init.h>
> #include <linux/list.h>
> #include <linux/mutex.h>
> #include <linux/rwsem.h>

Do you have a tool to detect those missing inclusions?

> 
> 
> > +#include "internals.h"
> > +
> > +static DEFINE_IDR(i3c_bus_idr);
> > +static DEFINE_MUTEX(i3c_core_lock);
> > +  
> 
> > +/**
> > + * i3c_bus_maintenance_lock - Release the bus lock after a maintenance  
> 
>                           unlock
> 

Will fix that.

> > + *			      operation
> > + * @bus: I3C bus to release the lock on
> > + *
> > + * Should be called when the bus maintenance operation is done. See
> > + * i3c_bus_maintenance_lock() for more details on what these maintenance
> > + * operations are.
> > + */
> > +void i3c_bus_maintenance_unlock(struct i3c_bus *bus)
> > +{
> > +	up_write(&bus->lock);
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_bus_maintenance_unlock);
> > +  
> 
> > +/**
> > + * i3c_bus_normaluse_lock - Release the bus lock after a normal operation  
> 
>                         unlock

Ditto.

> 
> > + * @bus: I3C bus to release the lock on
> > + *
> > + * Should be called when a normal operation is done. See
> > + * i3c_bus_normaluse_lock() for more details on what these normal operations
> > + * are.
> > + */
> > +void i3c_bus_normaluse_unlock(struct i3c_bus *bus)
> > +{
> > +	up_read(&bus->lock);
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_bus_normaluse_unlock);  
> 
> 
> 
> > +static int i3c_device_match(struct device *dev, struct device_driver *drv)  
> 
> bool?
> 
> > +{
> > +	struct i3c_device *i3cdev;
> > +	struct i3c_driver *i3cdrv;
> > +
> > +	if (dev->type != &i3c_device_type)
> > +		return 0;
> > +
> > +	i3cdev = dev_to_i3cdev(dev);
> > +	i3cdrv = drv_to_i3cdrv(drv);
> > +	if (i3c_device_match_id(i3cdev, i3cdrv->id_table))
> > +		return 1;
> > +
> > +	return 0;
> > +}  
> 
> 
> > diff --git a/drivers/i3c/device.c b/drivers/i3c/device.c
> > new file mode 100644
> > index 000000000000..dcf51150b7cb
> > --- /dev/null
> > +++ b/drivers/i3c/device.c
> > @@ -0,0 +1,344 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> > + */
> > +
> > +#include <linux/slab.h>  
> 
> #include <linux/atomic.h>
> #include <linux/bug.h>
> #include <linux/completion.h>
> #include <linux/device.h>
> #include <linux/mutex.h>
> 
> > +#include "internals.h"  
> 
> 
> 
> > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> > new file mode 100644
> > index 000000000000..1c85abac08d5
> > --- /dev/null
> > +++ b/drivers/i3c/master.c
> > @@ -0,0 +1,1433 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> > + */  
> 
> #include <linux/atomic.h>
> #include <linux/device.h>
> #include <linux/err.h>
> #include <linux/export.h>
> #include <linux/kernel.h>
> #include <linux/list.h>
> #include <linux/of.h>
> 
> > +#include <linux/slab.h>  
> 
> #include <linux/spinlock.h>
> #include <linux/workqueue.h>
> 
> #include <asm-generic/bug.h>
> 
> > +#include "internals.h"  
> 
> 
> and I probably missed a few.
> 
> 
> 
> 
> > diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h
> > new file mode 100644
> > index 000000000000..ff3e1a3e2c4c
> > --- /dev/null
> > +++ b/include/linux/i3c/ccc.h
> > @@ -0,0 +1,380 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> > + */  
> 
> > +/**
> > + * struct i3c_ccc_dev_desc - I3C/I3C device descriptor used for DEFSLVS  
> 
> Is one of those I3C above supposed to be I2C?

Indeed, should be I2C/I3C.

> 
> > + *
> > + * @dyn_addr: dynamic address assigned to the I3C slave or 0 if the entry is
> > + *	      describing an I2C slave.
> > + * @dcr: DCR value (not applicable to entries describing I2C devices)
> > + * @lvr: LVR value (not applicable to entries describing I3C devices)
> > + * @bcr: BCR value or 0 if this entry is describing an I2C slave
> > + * @static_addr: static address or 0 if the device does not have a static
> > + *		 address
> > + *
> > + * The DEFSLVS command should be passed an array of i3c_ccc_dev_desc
> > + * descriptors (one entry per I3C/I2C dev controlled by the master).
> > + */
> > +struct i3c_ccc_dev_desc {
> > +	u8 dyn_addr;
> > +	union {
> > +		u8 dcr;
> > +		u8 lvr;
> > +	};
> > +	u8 bcr;
> > +	u8 static_addr;
> > +} __packed;  
> 
> 
> Needs bitops.h
> 
> > diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h
> > new file mode 100644
> > index 000000000000..83958d3a02e2
> > --- /dev/null
> > +++ b/include/linux/i3c/device.h
> > @@ -0,0 +1,321 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> > + */
> > +
> > +#ifndef I3C_DEV_H
> > +#define I3C_DEV_H
> > +
> > +#include <linux/device.h>
> > +#include <linux/i2c.h>
> > +#include <linux/mod_devicetable.h>
> > +#include <linux/module.h>  
> 
> 
> Needs bitops.h, kconfig.h.
> 
> 
> > diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
> > new file mode 100644
> > index 000000000000..7ec9a4821bac
> > --- /dev/null
> > +++ b/include/linux/i3c/master.h
> > @@ -0,0 +1,564 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> > + */
> > +
> > +#ifndef I3C_MASTER_H
> > +#define I3C_MASTER_H
> > +
> > +#include <linux/i2c.h>
> > +#include <linux/i3c/ccc.h>
> > +#include <linux/i3c/device.h>
> > +#include <linux/spinlock.h>
> > +
> > +#define I3C_HOT_JOIN_ADDR		0x2
> > +#define I3C_BROADCAST_ADDR		0x7e
> > +#define I3C_MAX_ADDR			GENMASK(6, 0)
> > +  
> 
> Needs bitops.h, workqueue.h, rwsem.h
> 
> 
> Needs <asm-generic/bitsperlong.h>

Okay, that's really weird to directly include a header from the
asm-generic directory, are you sure this is the right thing to do here?

> 
> 
> 
> > diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> > index abb6dc2ebbf8..e59da92d8ac9 100644
> > --- a/include/linux/mod_devicetable.h
> > +++ b/include/linux/mod_devicetable.h
> > @@ -442,6 +442,23 @@ struct pci_epf_device_id {
> >  	kernel_ulong_t driver_data;
> >  };
> >  
> > +/* i3c */
> > +
> > +#define I3C_MATCH_DCR			BIT(0)
> > +#define I3C_MATCH_MANUF			BIT(1)
> > +#define I3C_MATCH_PART			BIT(2)
> > +#define I3C_MATCH_EXTRA_INFO		BIT(3)
> 
> Needs bitops.h.

I think I'll just avoid using BIT() here, as done for other definitions
in this file.

> 
> > +struct i3c_device_id {
> > +	__u8 match_flags;
> > +	__u8 dcr;
> > +	__u16 manuf_id;
> > +	__u16 part_id;
> > +	__u16 extra_info;
> > +
> > +	const void *data;
> > +};
> > +
> >  /* spi */
> >  
> >  #define SPI_NAME_SIZE	32
> >   
> 
> 

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2017-12-18  8:37     ` Boris Brezillon
@ 2017-12-18 18:22       ` Randy Dunlap
  0 siblings, 0 replies; 50+ messages in thread
From: Randy Dunlap @ 2017-12-18 18:22 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Vitor Soares, Geert Uytterhoeven, Linus Walleij

On 12/18/2017 12:37 AM, Boris Brezillon wrote:
> On Sun, 17 Dec 2017 14:32:04 -0800
> Randy Dunlap <rdunlap@infradead.org> wrote:
> 
>> On 12/14/17 07:16, Boris Brezillon wrote:
>>> Add core infrastructure to support I3C in Linux and document it.
>>>
>>> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>>> ---
>>>  drivers/Kconfig                 |    2 +
>>>  drivers/Makefile                |    2 +-
>>>  drivers/i3c/Kconfig             |   24 +
>>>  drivers/i3c/Makefile            |    4 +
>>>  drivers/i3c/core.c              |  573 ++++++++++++++++
>>>  drivers/i3c/device.c            |  344 ++++++++++
>>>  drivers/i3c/internals.h         |   34 +
>>>  drivers/i3c/master.c            | 1433 +++++++++++++++++++++++++++++++++++++++
>>>  drivers/i3c/master/Kconfig      |    0
>>>  drivers/i3c/master/Makefile     |    0
>>>  include/linux/i3c/ccc.h         |  380 +++++++++++
>>>  include/linux/i3c/device.h      |  321 +++++++++
>>>  include/linux/i3c/master.h      |  564 +++++++++++++++
>>>  include/linux/mod_devicetable.h |   17 +
>>>  14 files changed, 3697 insertions(+), 1 deletion(-)
>>>  create mode 100644 drivers/i3c/Kconfig
>>>  create mode 100644 drivers/i3c/Makefile
>>>  create mode 100644 drivers/i3c/core.c
>>>  create mode 100644 drivers/i3c/device.c
>>>  create mode 100644 drivers/i3c/internals.h
>>>  create mode 100644 drivers/i3c/master.c
>>>  create mode 100644 drivers/i3c/master/Kconfig
>>>  create mode 100644 drivers/i3c/master/Makefile
>>>  create mode 100644 include/linux/i3c/ccc.h
>>>  create mode 100644 include/linux/i3c/device.h
>>>  create mode 100644 include/linux/i3c/master.h


>>> diff --git a/drivers/i3c/core.c b/drivers/i3c/core.c
>>> new file mode 100644
>>> index 000000000000..7eb8e84acd33
>>> --- /dev/null
>>> +++ b/drivers/i3c/core.c
>>> @@ -0,0 +1,573 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
>>> + *
>>> + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
>>> + */
>>> +
>>> +#include <linux/idr.h>
>>> +#include <linux/module.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/slab.h>  
>>
>> #include <linux/device.h>
>> #include <linux/init.h>
>> #include <linux/list.h>
>> #include <linux/mutex.h>
>> #include <linux/rwsem.h>
> 
> Do you have a tool to detect those missing inclusions?

Nope, I've often wanted one, but for now it's just slow reading.



>>> diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
>>> new file mode 100644
>>> index 000000000000..7ec9a4821bac
>>> --- /dev/null
>>> +++ b/include/linux/i3c/master.h
>>> @@ -0,0 +1,564 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
>>> + *
>>> + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
>>> + */
>>> +
>>> +#ifndef I3C_MASTER_H
>>> +#define I3C_MASTER_H
>>> +
>>> +#include <linux/i2c.h>
>>> +#include <linux/i3c/ccc.h>
>>> +#include <linux/i3c/device.h>
>>> +#include <linux/spinlock.h>
>>> +
>>> +#define I3C_HOT_JOIN_ADDR		0x2
>>> +#define I3C_BROADCAST_ADDR		0x7e
>>> +#define I3C_MAX_ADDR			GENMASK(6, 0)
>>> +  
>>
>> Needs bitops.h, workqueue.h, rwsem.h
>>
>>
>> Needs <asm-generic/bitsperlong.h>
> 
> Okay, that's really weird to directly include a header from the
> asm-generic directory, are you sure this is the right thing to do here?

Looks like it should be <asm/bitsperlong.h>, which will grab the correct one.


-- 
~Randy

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2017-12-14 15:16 ` [PATCH v2 2/7] i3c: Add core I3C infrastructure Boris Brezillon
  2017-12-17 22:32   ` Randy Dunlap
@ 2017-12-19  8:52   ` Greg Kroah-Hartman
  2017-12-19  9:09     ` Boris Brezillon
  2018-02-23 16:28   ` Vitor Soares
  2018-02-23 16:56   ` Vitor Soares
  3 siblings, 1 reply; 50+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-19  8:52 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
	Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
	Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni,
	Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
	Geert Uytterhoeven, Linus Walleij

On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> +/**
> + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> + * @i3cdev: the I3C device we're searching a match for
> + * @id_table: the I3C device ID table
> + *
> + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> + *	   no match.
> + */
> +const struct i3c_device_id *
> +i3c_device_match_id(struct i3c_device *i3cdev,
> +		    const struct i3c_device_id *id_table)
> +{
> +	const struct i3c_device_id *id;
> +
> +	/*
> +	 * The lower 32bits of the provisional ID is just filled with a random
> +	 * value, try to match using DCR info.
> +	 */
> +	if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> +		u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> +		u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> +		u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> +
> +		/* First try to match by manufacturer/part ID. */
> +		for (id = id_table; id->match_flags != 0; id++) {
> +			if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> +			    I3C_MATCH_MANUF_AND_PART)
> +				continue;
> +
> +			if (manuf != id->manuf_id || part != id->part_id)
> +				continue;
> +
> +			if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> +			    ext_info != id->extra_info)
> +				continue;
> +
> +			return id;
> +		}
> +	}
> +
> +	/* Fallback to DCR match. */
> +	for (id = id_table; id->match_flags != 0; id++) {
> +		if ((id->match_flags & I3C_MATCH_DCR) &&
> +		    id->dcr == i3cdev->info.dcr)
> +			return id;
> +	}
> +
> +	return NULL;
> +}
> +EXPORT_SYMBOL_GPL(i3c_device_match_id);

I just picked one random export here, but it feels like you are
exporting a bunch of symbols you don't need to.  Why would something
outside of the i3c "core" need to call this function?  Have you looked
to see if you really have callers for everything you are exporting?

Other than that, the driver core interaction looks good now, nice job.

greg k-h

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2017-12-19  8:52   ` Greg Kroah-Hartman
@ 2017-12-19  9:09     ` Boris Brezillon
  2017-12-19  9:13       ` Boris Brezillon
  0 siblings, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2017-12-19  9:09 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
	Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
	Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni,
	Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
	Geert Uytterhoeven, Linus Walleij

On Tue, 19 Dec 2017 09:52:50 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> > +/**
> > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> > + * @i3cdev: the I3C device we're searching a match for
> > + * @id_table: the I3C device ID table
> > + *
> > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> > + *	   no match.
> > + */
> > +const struct i3c_device_id *
> > +i3c_device_match_id(struct i3c_device *i3cdev,
> > +		    const struct i3c_device_id *id_table)
> > +{
> > +	const struct i3c_device_id *id;
> > +
> > +	/*
> > +	 * The lower 32bits of the provisional ID is just filled with a random
> > +	 * value, try to match using DCR info.
> > +	 */
> > +	if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > +		u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > +		u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > +		u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > +
> > +		/* First try to match by manufacturer/part ID. */
> > +		for (id = id_table; id->match_flags != 0; id++) {
> > +			if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > +			    I3C_MATCH_MANUF_AND_PART)
> > +				continue;
> > +
> > +			if (manuf != id->manuf_id || part != id->part_id)
> > +				continue;
> > +
> > +			if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > +			    ext_info != id->extra_info)
> > +				continue;
> > +
> > +			return id;
> > +		}
> > +	}
> > +
> > +	/* Fallback to DCR match. */
> > +	for (id = id_table; id->match_flags != 0; id++) {
> > +		if ((id->match_flags & I3C_MATCH_DCR) &&
> > +		    id->dcr == i3cdev->info.dcr)
> > +			return id;
> > +	}
> > +
> > +	return NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_device_match_id);  
> 
> I just picked one random export here, but it feels like you are
> exporting a bunch of symbols you don't need to.  Why would something
> outside of the i3c "core" need to call this function?

Because I'm not passing the i3c_device_id to the ->probe() method, and
if the driver is supporting different variants of the device, it may
want to know which one is being probed.

I considered retrieving this information in the core just before probing
the driver and passing it to the ->probe() function, but it means
having an extra i3c_device_match_id() call for everyone even those who
don't care about the device_id information, so I thought exporting this
function was a good alternative (device drivers can use it when they
actually need to retrieve the device_id).

Anyway, that's something I can change if you think passing the
i3c_device_id to the ->probe() method is preferable.

> Have you looked
> to see if you really have callers for everything you are exporting?

Yes, I tried to only export functions that I think will be needed by
I3C device drivers and I3C master drivers. Note that I didn't post the
dummy device driver I developed to test the framework (partly because
this is 

> 
> Other than that, the driver core interaction looks good now, nice job.

Thanks.

Boris

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2017-12-19  9:09     ` Boris Brezillon
@ 2017-12-19  9:13       ` Boris Brezillon
  2017-12-19  9:21         ` Greg Kroah-Hartman
  0 siblings, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2017-12-19  9:13 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
	Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
	Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni,
	Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
	Geert Uytterhoeven, Linus Walleij

On Tue, 19 Dec 2017 10:09:00 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:

> On Tue, 19 Dec 2017 09:52:50 +0100
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:  
> > > +/**
> > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> > > + * @i3cdev: the I3C device we're searching a match for
> > > + * @id_table: the I3C device ID table
> > > + *
> > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> > > + *	   no match.
> > > + */
> > > +const struct i3c_device_id *
> > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > +		    const struct i3c_device_id *id_table)
> > > +{
> > > +	const struct i3c_device_id *id;
> > > +
> > > +	/*
> > > +	 * The lower 32bits of the provisional ID is just filled with a random
> > > +	 * value, try to match using DCR info.
> > > +	 */
> > > +	if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > +		u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > +		u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > +		u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > +
> > > +		/* First try to match by manufacturer/part ID. */
> > > +		for (id = id_table; id->match_flags != 0; id++) {
> > > +			if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > > +			    I3C_MATCH_MANUF_AND_PART)
> > > +				continue;
> > > +
> > > +			if (manuf != id->manuf_id || part != id->part_id)
> > > +				continue;
> > > +
> > > +			if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > +			    ext_info != id->extra_info)
> > > +				continue;
> > > +
> > > +			return id;
> > > +		}
> > > +	}
> > > +
> > > +	/* Fallback to DCR match. */
> > > +	for (id = id_table; id->match_flags != 0; id++) {
> > > +		if ((id->match_flags & I3C_MATCH_DCR) &&
> > > +		    id->dcr == i3cdev->info.dcr)
> > > +			return id;
> > > +	}
> > > +
> > > +	return NULL;
> > > +}
> > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);    
> > 
> > I just picked one random export here, but it feels like you are
> > exporting a bunch of symbols you don't need to.  Why would something
> > outside of the i3c "core" need to call this function?  
> 
> Because I'm not passing the i3c_device_id to the ->probe() method, and
> if the driver is supporting different variants of the device, it may
> want to know which one is being probed.
> 
> I considered retrieving this information in the core just before probing
> the driver and passing it to the ->probe() function, but it means
> having an extra i3c_device_match_id() call for everyone even those who
> don't care about the device_id information, so I thought exporting this
> function was a good alternative (device drivers can use it when they
> actually need to retrieve the device_id).
> 
> Anyway, that's something I can change if you think passing the
> i3c_device_id to the ->probe() method is preferable.
> 
> > Have you looked
> > to see if you really have callers for everything you are exporting?  
> 
> Yes, I tried to only export functions that I think will be needed by
> I3C device drivers and I3C master drivers. Note that I didn't post the
> dummy device driver I developed to test the framework (partly because
> this is 

Sorry, I hit the send button before finishing my sentence :-).

"
Note that I didn't post the dummy device driver [1] I developed to test
the framework (partly because the quality of the code does not meet
mainline standards and I was ashamed of posting it publicly :-)), but
this driver is using some of the exported functions.
"

[1]https://github.com/bbrezillon/linux-0day/commit/10054caf3493524b6ae352a1bdcb71e82c885a6e

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2017-12-19  9:13       ` Boris Brezillon
@ 2017-12-19  9:21         ` Greg Kroah-Hartman
  2017-12-19  9:28           ` Boris Brezillon
  0 siblings, 1 reply; 50+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-19  9:21 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
	Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
	Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni,
	Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
	Geert Uytterhoeven, Linus Walleij

On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote:
> On Tue, 19 Dec 2017 10:09:00 +0100
> Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> 
> > On Tue, 19 Dec 2017 09:52:50 +0100
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > 
> > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:  
> > > > +/**
> > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> > > > + * @i3cdev: the I3C device we're searching a match for
> > > > + * @id_table: the I3C device ID table
> > > > + *
> > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> > > > + *	   no match.
> > > > + */
> > > > +const struct i3c_device_id *
> > > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > > +		    const struct i3c_device_id *id_table)
> > > > +{
> > > > +	const struct i3c_device_id *id;
> > > > +
> > > > +	/*
> > > > +	 * The lower 32bits of the provisional ID is just filled with a random
> > > > +	 * value, try to match using DCR info.
> > > > +	 */
> > > > +	if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > > +		u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > > +		u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > > +		u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > > +
> > > > +		/* First try to match by manufacturer/part ID. */
> > > > +		for (id = id_table; id->match_flags != 0; id++) {
> > > > +			if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > > > +			    I3C_MATCH_MANUF_AND_PART)
> > > > +				continue;
> > > > +
> > > > +			if (manuf != id->manuf_id || part != id->part_id)
> > > > +				continue;
> > > > +
> > > > +			if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > > +			    ext_info != id->extra_info)
> > > > +				continue;
> > > > +
> > > > +			return id;
> > > > +		}
> > > > +	}
> > > > +
> > > > +	/* Fallback to DCR match. */
> > > > +	for (id = id_table; id->match_flags != 0; id++) {
> > > > +		if ((id->match_flags & I3C_MATCH_DCR) &&
> > > > +		    id->dcr == i3cdev->info.dcr)
> > > > +			return id;
> > > > +	}
> > > > +
> > > > +	return NULL;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);    
> > > 
> > > I just picked one random export here, but it feels like you are
> > > exporting a bunch of symbols you don't need to.  Why would something
> > > outside of the i3c "core" need to call this function?  
> > 
> > Because I'm not passing the i3c_device_id to the ->probe() method, and
> > if the driver is supporting different variants of the device, it may
> > want to know which one is being probed.
> > 
> > I considered retrieving this information in the core just before probing
> > the driver and passing it to the ->probe() function, but it means
> > having an extra i3c_device_match_id() call for everyone even those who
> > don't care about the device_id information, so I thought exporting this
> > function was a good alternative (device drivers can use it when they
> > actually need to retrieve the device_id).
> > 
> > Anyway, that's something I can change if you think passing the
> > i3c_device_id to the ->probe() method is preferable.
> > 
> > > Have you looked
> > > to see if you really have callers for everything you are exporting?  
> > 
> > Yes, I tried to only export functions that I think will be needed by
> > I3C device drivers and I3C master drivers. Note that I didn't post the
> > dummy device driver I developed to test the framework (partly because
> > this is 
> 
> Sorry, I hit the send button before finishing my sentence :-).
> 
> "
> Note that I didn't post the dummy device driver [1] I developed to test
> the framework (partly because the quality of the code does not meet
> mainline standards and I was ashamed of posting it publicly :-)), but
> this driver is using some of the exported functions.
> "

We don't export functions that has no in-kernel users :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2017-12-19  9:21         ` Greg Kroah-Hartman
@ 2017-12-19  9:28           ` Boris Brezillon
  2017-12-19  9:36             ` Greg Kroah-Hartman
  0 siblings, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2017-12-19  9:28 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
	Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
	Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni,
	Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
	Geert Uytterhoeven, Linus Walleij

On Tue, 19 Dec 2017 10:21:19 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote:
> > On Tue, 19 Dec 2017 10:09:00 +0100
> > Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> >   
> > > On Tue, 19 Dec 2017 09:52:50 +0100
> > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > >   
> > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:    
> > > > > +/**
> > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> > > > > + * @i3cdev: the I3C device we're searching a match for
> > > > > + * @id_table: the I3C device ID table
> > > > > + *
> > > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> > > > > + *	   no match.
> > > > > + */
> > > > > +const struct i3c_device_id *
> > > > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > > > +		    const struct i3c_device_id *id_table)
> > > > > +{
> > > > > +	const struct i3c_device_id *id;
> > > > > +
> > > > > +	/*
> > > > > +	 * The lower 32bits of the provisional ID is just filled with a random
> > > > > +	 * value, try to match using DCR info.
> > > > > +	 */
> > > > > +	if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > > > +		u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > > > +		u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > > > +		u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > > > +
> > > > > +		/* First try to match by manufacturer/part ID. */
> > > > > +		for (id = id_table; id->match_flags != 0; id++) {
> > > > > +			if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > > > > +			    I3C_MATCH_MANUF_AND_PART)
> > > > > +				continue;
> > > > > +
> > > > > +			if (manuf != id->manuf_id || part != id->part_id)
> > > > > +				continue;
> > > > > +
> > > > > +			if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > > > +			    ext_info != id->extra_info)
> > > > > +				continue;
> > > > > +
> > > > > +			return id;
> > > > > +		}
> > > > > +	}
> > > > > +
> > > > > +	/* Fallback to DCR match. */
> > > > > +	for (id = id_table; id->match_flags != 0; id++) {
> > > > > +		if ((id->match_flags & I3C_MATCH_DCR) &&
> > > > > +		    id->dcr == i3cdev->info.dcr)
> > > > > +			return id;
> > > > > +	}
> > > > > +
> > > > > +	return NULL;
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);      
> > > > 
> > > > I just picked one random export here, but it feels like you are
> > > > exporting a bunch of symbols you don't need to.  Why would something
> > > > outside of the i3c "core" need to call this function?    
> > > 
> > > Because I'm not passing the i3c_device_id to the ->probe() method, and
> > > if the driver is supporting different variants of the device, it may
> > > want to know which one is being probed.
> > > 
> > > I considered retrieving this information in the core just before probing
> > > the driver and passing it to the ->probe() function, but it means
> > > having an extra i3c_device_match_id() call for everyone even those who
> > > don't care about the device_id information, so I thought exporting this
> > > function was a good alternative (device drivers can use it when they
> > > actually need to retrieve the device_id).
> > > 
> > > Anyway, that's something I can change if you think passing the
> > > i3c_device_id to the ->probe() method is preferable.
> > >   
> > > > Have you looked
> > > > to see if you really have callers for everything you are exporting?    
> > > 
> > > Yes, I tried to only export functions that I think will be needed by
> > > I3C device drivers and I3C master drivers. Note that I didn't post the
> > > dummy device driver I developed to test the framework (partly because
> > > this is   
> > 
> > Sorry, I hit the send button before finishing my sentence :-).
> > 
> > "
> > Note that I didn't post the dummy device driver [1] I developed to test
> > the framework (partly because the quality of the code does not meet
> > mainline standards and I was ashamed of posting it publicly :-)), but
> > this driver is using some of the exported functions.
> > "  
> 
> We don't export functions that has no in-kernel users :)

But then, I can't export device driver related functions, because
there's no official device driver yet :-). So what should I do?

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2017-12-19  9:28           ` Boris Brezillon
@ 2017-12-19  9:36             ` Greg Kroah-Hartman
  2018-02-21 14:22               ` Boris Brezillon
  0 siblings, 1 reply; 50+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-19  9:36 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
	Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
	Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni,
	Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
	Geert Uytterhoeven, Linus Walleij

On Tue, Dec 19, 2017 at 10:28:58AM +0100, Boris Brezillon wrote:
> On Tue, 19 Dec 2017 10:21:19 +0100
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> > On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote:
> > > On Tue, 19 Dec 2017 10:09:00 +0100
> > > Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> > >   
> > > > On Tue, 19 Dec 2017 09:52:50 +0100
> > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > >   
> > > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:    
> > > > > > +/**
> > > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> > > > > > + * @i3cdev: the I3C device we're searching a match for
> > > > > > + * @id_table: the I3C device ID table
> > > > > > + *
> > > > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> > > > > > + *	   no match.
> > > > > > + */
> > > > > > +const struct i3c_device_id *
> > > > > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > > > > +		    const struct i3c_device_id *id_table)
> > > > > > +{
> > > > > > +	const struct i3c_device_id *id;
> > > > > > +
> > > > > > +	/*
> > > > > > +	 * The lower 32bits of the provisional ID is just filled with a random
> > > > > > +	 * value, try to match using DCR info.
> > > > > > +	 */
> > > > > > +	if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > > > > +		u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > > > > +		u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > > > > +		u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > > > > +
> > > > > > +		/* First try to match by manufacturer/part ID. */
> > > > > > +		for (id = id_table; id->match_flags != 0; id++) {
> > > > > > +			if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > > > > > +			    I3C_MATCH_MANUF_AND_PART)
> > > > > > +				continue;
> > > > > > +
> > > > > > +			if (manuf != id->manuf_id || part != id->part_id)
> > > > > > +				continue;
> > > > > > +
> > > > > > +			if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > > > > +			    ext_info != id->extra_info)
> > > > > > +				continue;
> > > > > > +
> > > > > > +			return id;
> > > > > > +		}
> > > > > > +	}
> > > > > > +
> > > > > > +	/* Fallback to DCR match. */
> > > > > > +	for (id = id_table; id->match_flags != 0; id++) {
> > > > > > +		if ((id->match_flags & I3C_MATCH_DCR) &&
> > > > > > +		    id->dcr == i3cdev->info.dcr)
> > > > > > +			return id;
> > > > > > +	}
> > > > > > +
> > > > > > +	return NULL;
> > > > > > +}
> > > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);      
> > > > > 
> > > > > I just picked one random export here, but it feels like you are
> > > > > exporting a bunch of symbols you don't need to.  Why would something
> > > > > outside of the i3c "core" need to call this function?    
> > > > 
> > > > Because I'm not passing the i3c_device_id to the ->probe() method, and
> > > > if the driver is supporting different variants of the device, it may
> > > > want to know which one is being probed.
> > > > 
> > > > I considered retrieving this information in the core just before probing
> > > > the driver and passing it to the ->probe() function, but it means
> > > > having an extra i3c_device_match_id() call for everyone even those who
> > > > don't care about the device_id information, so I thought exporting this
> > > > function was a good alternative (device drivers can use it when they
> > > > actually need to retrieve the device_id).
> > > > 
> > > > Anyway, that's something I can change if you think passing the
> > > > i3c_device_id to the ->probe() method is preferable.
> > > >   
> > > > > Have you looked
> > > > > to see if you really have callers for everything you are exporting?    
> > > > 
> > > > Yes, I tried to only export functions that I think will be needed by
> > > > I3C device drivers and I3C master drivers. Note that I didn't post the
> > > > dummy device driver I developed to test the framework (partly because
> > > > this is   
> > > 
> > > Sorry, I hit the send button before finishing my sentence :-).
> > > 
> > > "
> > > Note that I didn't post the dummy device driver [1] I developed to test
> > > the framework (partly because the quality of the code does not meet
> > > mainline standards and I was ashamed of posting it publicly :-)), but
> > > this driver is using some of the exported functions.
> > > "  
> > 
> > We don't export functions that has no in-kernel users :)
> 
> But then, I can't export device driver related functions, because
> there's no official device driver yet :-). So what should I do?

Export them when you have a driver.  Or better yet, submit a driver as
part of the patch series.  Why would we want infrastructure that no one
uses?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
  2017-12-16 18:35     ` Boris Brezillon
@ 2017-12-20 18:06       ` Rob Herring
  2017-12-21 10:41         ` Boris Brezillon
  0 siblings, 1 reply; 50+ messages in thread
From: Rob Herring @ 2017-12-20 18:06 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
	Geert Uytterhoeven, Linus Walleij

On Sat, Dec 16, 2017 at 07:35:37PM +0100, Boris Brezillon wrote:
> On Sat, 16 Dec 2017 11:20:40 -0600
> Rob Herring <robh@kernel.org> wrote:
> 
> > On Thu, Dec 14, 2017 at 04:16:08PM +0100, Boris Brezillon wrote:
> > > A new I3C subsystem has been added and a generic description has been
> > > created to represent the I3C bus and the devices connected on it.
> > > 
> > > Document this generic representation.

[...]

> > So please define the node 
> > name to be "i3c-controller". That's more inline with other node names 
> > than i3c-master that you used below.
> 
> Hm, not sure i3c-controller is appropriate though, because you can have
> slave controllers. Maybe i3c-host, but I'd prefer to keep the term
> master since it's employed everywhere in the spec. I can also be
> i3c-master-controller if you prefer.

Okay, i3c-master is fine. Just make it explicit.

> > > +I3C devices
> > > +===========
> > > +
> > > +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
> > > +are thus discoverable. So, by default, I3C devices do not have to be described
> > > +in the device tree.
> > > +This being said, one might want to attach extra resources to these devices,
> > > +and those resources may have to be described in the device tree, which in turn
> > > +means we have to describe I3C devices.
> > > +
> > > +Another use case for describing an I3C device in the device tree is when this
> > > +I3C device has a static address and we want to assign it a specific dynamic
> > > +address before the DAA takes place (so that other devices on the bus can't
> > > +take this dynamic address).
> > > +
> > > +Required properties
> > > +-------------------
> > > +- i3c-pid: PID (Provisional ID). 64-bit property which is used to match a
> > > +	   device discovered during DAA with its device tree definition. The
> > > +	   PID is supposed to be unique on a given bus, which guarantees a 1:1
> > > +	   match. This property becomes optional if a reg property is defined,
> > > +	   meaning that the device has a static address.  
> > 
> > What determines this number?
> 
> Part of it is fixed (manufacturer and part id) and the last few bits
> represent the device instance on the bus (so you can have several
> identical devices on the same bus). The manufacturer and part ids
> should be statically assigned during production, instance id is usually
> configurable through extra pins that you drive high or low at reset
> time.

Sounds like an I2C address at least for the pin strapping part...

> > > +
> > > +Optional properties
> > > +-------------------
> > > +- reg: static address. Only valid is the device has a static address.
> > > +- i3c-dynamic-address: dynamic address to be assigned to this device. This
> > > +		       property depends on the reg property.  
> > 
> > Perhaps "assigned-address" property would be appropriate. I'm not all 
> > that familiar with it though.
> 
> Again, the spec use the term "dynamic address" everywhere, and I'd like
> to stay as close as possible to the spec.

I looked at assigned-addresses a bit more and that won't really fit 
because it should be the same format as reg. So I think reg should 
always be the PID as that is fixed and always present. Then the DAA 
address is separate and can be the i3c-dynamic-address property.

However, there's still part I don't understand...

> > > +		/* I3C device with a static address. */
> > > +		thermal_sensor: sensor@68 {
> > > +			reg = <0x68>;
> > > +			i3c-dynamic-address = <0xa>;

I'm confused as to how/why you have both reg and dynamic address?

> > > +		};
> > > +
> > > +		/*
> > > +		 * I3C device without a static address but requiring resources
> > > +		 * described in the DT.
> > > +		 */
> > > +		sensor2 {  
> > 
> > It's not great that we can't follow using generic node names. Maybe the 
> > PID can be used as the address? In USB for example, we use hub ports for 
> > DT addresses rather than USB addresses since those are dynamic.
> 
> Hm, the problem is, we may have 2 numbering schemes here: one where reg
> is used (reg representing the I2C/static address), and another one
> where the PID is used.
> If you're okay with mixing those 2 schemes, then I'm fine with that too.

Mixing I2C devices and I3C devices, yes. But you need to mix in a single 
device? IOW, do I3C devices also have an I2C address?

Rob

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
  2017-12-20 18:06       ` Rob Herring
@ 2017-12-21 10:41         ` Boris Brezillon
  2017-12-26 18:29           ` Rob Herring
  0 siblings, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2017-12-21 10:41 UTC (permalink / raw)
  To: Rob Herring
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
	Geert Uytterhoeven, Linus Walleij

On Wed, 20 Dec 2017 12:06:45 -0600
Rob Herring <robh@kernel.org> wrote:

> On Sat, Dec 16, 2017 at 07:35:37PM +0100, Boris Brezillon wrote:
> > On Sat, 16 Dec 2017 11:20:40 -0600
> > Rob Herring <robh@kernel.org> wrote:
> >   
> > > On Thu, Dec 14, 2017 at 04:16:08PM +0100, Boris Brezillon wrote:  
> > > > A new I3C subsystem has been added and a generic description has been
> > > > created to represent the I3C bus and the devices connected on it.
> > > > 
> > > > Document this generic representation.  
> 
> [...]
> 
> > > So please define the node 
> > > name to be "i3c-controller". That's more inline with other node names 
> > > than i3c-master that you used below.  
> > 
> > Hm, not sure i3c-controller is appropriate though, because you can have
> > slave controllers. Maybe i3c-host, but I'd prefer to keep the term
> > master since it's employed everywhere in the spec. I can also be
> > i3c-master-controller if you prefer.  
> 
> Okay, i3c-master is fine. Just make it explicit.

Okay.

> 
> > > > +I3C devices
> > > > +===========
> > > > +
> > > > +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
> > > > +are thus discoverable. So, by default, I3C devices do not have to be described
> > > > +in the device tree.
> > > > +This being said, one might want to attach extra resources to these devices,
> > > > +and those resources may have to be described in the device tree, which in turn
> > > > +means we have to describe I3C devices.
> > > > +
> > > > +Another use case for describing an I3C device in the device tree is when this
> > > > +I3C device has a static address and we want to assign it a specific dynamic
> > > > +address before the DAA takes place (so that other devices on the bus can't
> > > > +take this dynamic address).
> > > > +
> > > > +Required properties
> > > > +-------------------
> > > > +- i3c-pid: PID (Provisional ID). 64-bit property which is used to match a
> > > > +	   device discovered during DAA with its device tree definition. The
> > > > +	   PID is supposed to be unique on a given bus, which guarantees a 1:1
> > > > +	   match. This property becomes optional if a reg property is defined,
> > > > +	   meaning that the device has a static address.    
> > > 
> > > What determines this number?  
> > 
> > Part of it is fixed (manufacturer and part id) and the last few bits
> > represent the device instance on the bus (so you can have several
> > identical devices on the same bus). The manufacturer and part ids
> > should be statically assigned during production, instance id is usually
> > configurable through extra pins that you drive high or low at reset
> > time.  
> 
> Sounds like an I2C address at least for the pin strapping part...

The address space of this instance-id is smaller (4bits) than the I2C
one (7bits), and more importantly, the instance-id is not required to
be unique, it's the aggregation of the vendor-id, part-id and
instance-id that has to be unique. So, if you were thinking about using
this id to uniquely identify the device on the bus it's not a good idea.

> 
> > > > +
> > > > +Optional properties
> > > > +-------------------
> > > > +- reg: static address. Only valid is the device has a static address.
> > > > +- i3c-dynamic-address: dynamic address to be assigned to this device. This
> > > > +		       property depends on the reg property.    
> > > 
> > > Perhaps "assigned-address" property would be appropriate. I'm not all 
> > > that familiar with it though.  
> > 
> > Again, the spec use the term "dynamic address" everywhere, and I'd like
> > to stay as close as possible to the spec.  
> 
> I looked at assigned-addresses a bit more and that won't really fit 
> because it should be the same format as reg. So I think reg should 
> always be the PID as that is fixed and always present. Then the DAA 
> address is separate and can be the i3c-dynamic-address property.
> 
> However, there's still part I don't understand...
> 
> > > > +		/* I3C device with a static address. */
> > > > +		thermal_sensor: sensor@68 {
> > > > +			reg = <0x68>;
> > > > +			i3c-dynamic-address = <0xa>;  
> 
> I'm confused as to how/why you have both reg and dynamic address?

Some I3C devices have an I2C address (also called static or legacy
address in a few places). The static/I2C/legacy address is used until
the I3C device is assigned a dynamic address by the master. The whole
point of specifying both an I2C address (through the reg property) and
a dynamic address (through the i3c-dynamic-address) is to tell the
controller that a specific dynamic address should be assigned to this
device using the SETSADA (Set Dynamic Address from Static Address)
command before a DAA (Dynamic Address Assignment) procedure is started.
This way, the device will not participate to the DAA (because it
already has a valid DA) and the dynamic address can't be assigned to
a different device (which is one of the problem with the automatic DAA
procedure).

> 
> > > > +		};
> > > > +
> > > > +		/*
> > > > +		 * I3C device without a static address but requiring resources
> > > > +		 * described in the DT.
> > > > +		 */
> > > > +		sensor2 {    
> > > 
> > > It's not great that we can't follow using generic node names. Maybe the 
> > > PID can be used as the address? In USB for example, we use hub ports for 
> > > DT addresses rather than USB addresses since those are dynamic.  
> > 
> > Hm, the problem is, we may have 2 numbering schemes here: one where reg
> > is used (reg representing the I2C/static address), and another one
> > where the PID is used.
> > If you're okay with mixing those 2 schemes, then I'm fine with that too.  
> 
> Mixing I2C devices and I3C devices, yes. But you need to mix in a single 
> device? IOW, do I3C devices also have an I2C address?

Yes, some of them have both.

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
  2017-12-21 10:41         ` Boris Brezillon
@ 2017-12-26 18:29           ` Rob Herring
  2018-01-07 14:14             ` Boris Brezillon
  0 siblings, 1 reply; 50+ messages in thread
From: Rob Herring @ 2017-12-26 18:29 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij

On Thu, Dec 21, 2017 at 4:41 AM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> On Wed, 20 Dec 2017 12:06:45 -0600
> Rob Herring <robh@kernel.org> wrote:
>
>> On Sat, Dec 16, 2017 at 07:35:37PM +0100, Boris Brezillon wrote:
>> > On Sat, 16 Dec 2017 11:20:40 -0600
>> > Rob Herring <robh@kernel.org> wrote:
>> >
>> > > On Thu, Dec 14, 2017 at 04:16:08PM +0100, Boris Brezillon wrote:
>> > > > A new I3C subsystem has been added and a generic description has been
>> > > > created to represent the I3C bus and the devices connected on it.
>> > > >
>> > > > Document this generic representation.
>>
>> [...]
>>
>> > > So please define the node
>> > > name to be "i3c-controller". That's more inline with other node names
>> > > than i3c-master that you used below.
>> >
>> > Hm, not sure i3c-controller is appropriate though, because you can have
>> > slave controllers. Maybe i3c-host, but I'd prefer to keep the term
>> > master since it's employed everywhere in the spec. I can also be
>> > i3c-master-controller if you prefer.
>>
>> Okay, i3c-master is fine. Just make it explicit.
>
> Okay.
>
>>
>> > > > +I3C devices
>> > > > +===========
>> > > > +
>> > > > +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
>> > > > +are thus discoverable. So, by default, I3C devices do not have to be described
>> > > > +in the device tree.
>> > > > +This being said, one might want to attach extra resources to these devices,
>> > > > +and those resources may have to be described in the device tree, which in turn
>> > > > +means we have to describe I3C devices.
>> > > > +
>> > > > +Another use case for describing an I3C device in the device tree is when this
>> > > > +I3C device has a static address and we want to assign it a specific dynamic
>> > > > +address before the DAA takes place (so that other devices on the bus can't
>> > > > +take this dynamic address).
>> > > > +
>> > > > +Required properties
>> > > > +-------------------
>> > > > +- i3c-pid: PID (Provisional ID). 64-bit property which is used to match a
>> > > > +          device discovered during DAA with its device tree definition. The
>> > > > +          PID is supposed to be unique on a given bus, which guarantees a 1:1
>> > > > +          match. This property becomes optional if a reg property is defined,
>> > > > +          meaning that the device has a static address.
>> > >
>> > > What determines this number?
>> >
>> > Part of it is fixed (manufacturer and part id) and the last few bits
>> > represent the device instance on the bus (so you can have several
>> > identical devices on the same bus). The manufacturer and part ids
>> > should be statically assigned during production, instance id is usually
>> > configurable through extra pins that you drive high or low at reset
>> > time.
>>
>> Sounds like an I2C address at least for the pin strapping part...
>
> The address space of this instance-id is smaller (4bits) than the I2C
> one (7bits), and more importantly, the instance-id is not required to
> be unique, it's the aggregation of the vendor-id, part-id and
> instance-id that has to be unique. So, if you were thinking about using
> this id to uniquely identify the device on the bus it's not a good idea.

No, no. I was just commenting how I2C devices typically do the same
pin strapping to make addresses unique.


>> > > > +Optional properties
>> > > > +-------------------
>> > > > +- reg: static address. Only valid is the device has a static address.
>> > > > +- i3c-dynamic-address: dynamic address to be assigned to this device. This
>> > > > +                      property depends on the reg property.
>> > >
>> > > Perhaps "assigned-address" property would be appropriate. I'm not all
>> > > that familiar with it though.
>> >
>> > Again, the spec use the term "dynamic address" everywhere, and I'd like
>> > to stay as close as possible to the spec.
>>
>> I looked at assigned-addresses a bit more and that won't really fit
>> because it should be the same format as reg. So I think reg should
>> always be the PID as that is fixed and always present. Then the DAA
>> address is separate and can be the i3c-dynamic-address property.
>>
>> However, there's still part I don't understand...
>>
>> > > > +               /* I3C device with a static address. */
>> > > > +               thermal_sensor: sensor@68 {
>> > > > +                       reg = <0x68>;
>> > > > +                       i3c-dynamic-address = <0xa>;
>>
>> I'm confused as to how/why you have both reg and dynamic address?
>
> Some I3C devices have an I2C address (also called static or legacy
> address in a few places). The static/I2C/legacy address is used until
> the I3C device is assigned a dynamic address by the master. The whole
> point of specifying both an I2C address (through the reg property) and
> a dynamic address (through the i3c-dynamic-address) is to tell the
> controller that a specific dynamic address should be assigned to this
> device using the SETSADA (Set Dynamic Address from Static Address)
> command before a DAA (Dynamic Address Assignment) procedure is started.
> This way, the device will not participate to the DAA (because it
> already has a valid DA) and the dynamic address can't be assigned to
> a different device (which is one of the problem with the automatic DAA
> procedure).

Okay, think I got it now.

I think we should extend "reg" to have either I2C address, I3C PID, or
both (in a defined order). I'm assuming you can always distinguish a
static I2C address and an I3C PID just by upper bits all being 0s for
I2C addresses. Maybe both is not needed? This means we'd have to allow
64-bit I2C addresses (#address-cells=2), but that should be easily
fixed if that causes problems in the kernel.

So i3c-pid would go away and i3c-dynamic-address stays.

Rob

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
  2017-12-26 18:29           ` Rob Herring
@ 2018-01-07 14:14             ` Boris Brezillon
  2018-01-22  8:47               ` Boris Brezillon
  0 siblings, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2018-01-07 14:14 UTC (permalink / raw)
  To: Rob Herring
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij

Hi Rob,

On Tue, 26 Dec 2017 12:29:34 -0600
Rob Herring <robh@kernel.org> wrote:

> >> > > > +Optional properties
> >> > > > +-------------------
> >> > > > +- reg: static address. Only valid is the device has a static address.
> >> > > > +- i3c-dynamic-address: dynamic address to be assigned to this device. This
> >> > > > +                      property depends on the reg property.  
> >> > >
> >> > > Perhaps "assigned-address" property would be appropriate. I'm not all
> >> > > that familiar with it though.  
> >> >
> >> > Again, the spec use the term "dynamic address" everywhere, and I'd like
> >> > to stay as close as possible to the spec.  
> >>
> >> I looked at assigned-addresses a bit more and that won't really fit
> >> because it should be the same format as reg. So I think reg should
> >> always be the PID as that is fixed and always present. Then the DAA
> >> address is separate and can be the i3c-dynamic-address property.
> >>
> >> However, there's still part I don't understand...
> >>  
> >> > > > +               /* I3C device with a static address. */
> >> > > > +               thermal_sensor: sensor@68 {
> >> > > > +                       reg = <0x68>;
> >> > > > +                       i3c-dynamic-address = <0xa>;  
> >>
> >> I'm confused as to how/why you have both reg and dynamic address?  
> >
> > Some I3C devices have an I2C address (also called static or legacy
> > address in a few places). The static/I2C/legacy address is used until
> > the I3C device is assigned a dynamic address by the master. The whole
> > point of specifying both an I2C address (through the reg property) and
> > a dynamic address (through the i3c-dynamic-address) is to tell the
> > controller that a specific dynamic address should be assigned to this
> > device using the SETSADA (Set Dynamic Address from Static Address)
> > command before a DAA (Dynamic Address Assignment) procedure is started.
> > This way, the device will not participate to the DAA (because it
> > already has a valid DA) and the dynamic address can't be assigned to
> > a different device (which is one of the problem with the automatic DAA
> > procedure).  
> 
> Okay, think I got it now.
> 
> I think we should extend "reg" to have either I2C address, I3C PID, or
> both (in a defined order). I'm assuming you can always distinguish a
> static I2C address and an I3C PID just by upper bits all being 0s for
> I2C addresses. Maybe both is not needed? This means we'd have to allow
> 64-bit I2C addresses (#address-cells=2), but that should be easily
> fixed if that causes problems in the kernel.
> 
> So i3c-pid would go away and i3c-dynamic-address stays.

Hm, actually I'm not sure this is a good idea. Sounds like we're
abusing the purpose of reg here. For busses, reg is supposed to encode
the id of the device on the bus that is used to communicate with this
device (CS line for SPI, I2C address for I2C devs, ...). With I3C, the
PID is just a way to uniquely identify a device, but is not used during
communications (we either use the static/I2C address or the dynamic
address assigned by the master).

If your concern is just about I3C dev naming convention, maybe we
could have something like:

	i3c-master@xxxx {
		...
		i2cdev@xx {
			reg = <xx>;
			i3c-lvr = <yy>;
			...
		};
		...

		i3cdev-<i3c-pid>[@zz] {
			i3c-pid = <pppppp>;
			/*
			 * reg only defined if the device has a static
			 * address.
			 */
			[reg = <zz>;]
			/*
			 * i3c-dynamic-address only defined if a
			 * specific dynamic address is requested.
			 */
			[i3c-dynamic-address = <dd>;]
		};
	}; 

With this approach we have a way to quickly identify i3c devices by
their pid when looking at their names (with the -<i3c-pid> suffix), and
we keep reg for static/i2c addresses only.

Regards,

Boris

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
  2018-01-07 14:14             ` Boris Brezillon
@ 2018-01-22  8:47               ` Boris Brezillon
  0 siblings, 0 replies; 50+ messages in thread
From: Boris Brezillon @ 2018-01-22  8:47 UTC (permalink / raw)
  To: Rob Herring
  Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
	Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij

Hi Rob,

On Sun, 7 Jan 2018 15:14:25 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:

> Hi Rob,
> 
> On Tue, 26 Dec 2017 12:29:34 -0600
> Rob Herring <robh@kernel.org> wrote:
> 
> > >> > > > +Optional properties
> > >> > > > +-------------------
> > >> > > > +- reg: static address. Only valid is the device has a static address.
> > >> > > > +- i3c-dynamic-address: dynamic address to be assigned to this device. This
> > >> > > > +                      property depends on the reg property.    
> > >> > >
> > >> > > Perhaps "assigned-address" property would be appropriate. I'm not all
> > >> > > that familiar with it though.    
> > >> >
> > >> > Again, the spec use the term "dynamic address" everywhere, and I'd like
> > >> > to stay as close as possible to the spec.    
> > >>
> > >> I looked at assigned-addresses a bit more and that won't really fit
> > >> because it should be the same format as reg. So I think reg should
> > >> always be the PID as that is fixed and always present. Then the DAA
> > >> address is separate and can be the i3c-dynamic-address property.
> > >>
> > >> However, there's still part I don't understand...
> > >>    
> > >> > > > +               /* I3C device with a static address. */
> > >> > > > +               thermal_sensor: sensor@68 {
> > >> > > > +                       reg = <0x68>;
> > >> > > > +                       i3c-dynamic-address = <0xa>;    
> > >>
> > >> I'm confused as to how/why you have both reg and dynamic address?    
> > >
> > > Some I3C devices have an I2C address (also called static or legacy
> > > address in a few places). The static/I2C/legacy address is used until
> > > the I3C device is assigned a dynamic address by the master. The whole
> > > point of specifying both an I2C address (through the reg property) and
> > > a dynamic address (through the i3c-dynamic-address) is to tell the
> > > controller that a specific dynamic address should be assigned to this
> > > device using the SETSADA (Set Dynamic Address from Static Address)
> > > command before a DAA (Dynamic Address Assignment) procedure is started.
> > > This way, the device will not participate to the DAA (because it
> > > already has a valid DA) and the dynamic address can't be assigned to
> > > a different device (which is one of the problem with the automatic DAA
> > > procedure).    
> > 
> > Okay, think I got it now.
> > 
> > I think we should extend "reg" to have either I2C address, I3C PID, or
> > both (in a defined order). I'm assuming you can always distinguish a
> > static I2C address and an I3C PID just by upper bits all being 0s for
> > I2C addresses. Maybe both is not needed? This means we'd have to allow
> > 64-bit I2C addresses (#address-cells=2), but that should be easily
> > fixed if that causes problems in the kernel.
> > 
> > So i3c-pid would go away and i3c-dynamic-address stays.  
> 
> Hm, actually I'm not sure this is a good idea. Sounds like we're
> abusing the purpose of reg here. For busses, reg is supposed to encode
> the id of the device on the bus that is used to communicate with this
> device (CS line for SPI, I2C address for I2C devs, ...). With I3C, the
> PID is just a way to uniquely identify a device, but is not used during
> communications (we either use the static/I2C address or the dynamic
> address assigned by the master).
> 
> If your concern is just about I3C dev naming convention, maybe we
> could have something like:
> 
> 	i3c-master@xxxx {
> 		...
> 		i2cdev@xx {
> 			reg = <xx>;
> 			i3c-lvr = <yy>;
> 			...
> 		};
> 		...
> 
> 		i3cdev-<i3c-pid>[@zz] {
> 			i3c-pid = <pppppp>;
> 			/*
> 			 * reg only defined if the device has a static
> 			 * address.
> 			 */
> 			[reg = <zz>;]
> 			/*
> 			 * i3c-dynamic-address only defined if a
> 			 * specific dynamic address is requested.
> 			 */
> 			[i3c-dynamic-address = <dd>;]
> 		};
> 	}; 
> 
> With this approach we have a way to quickly identify i3c devices by
> their pid when looking at their names (with the -<i3c-pid> suffix), and
> we keep reg for static/i2c addresses only.

Did you have time to read this email (AKA ping)?

Regards,

Boris

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2017-12-19  9:36             ` Greg Kroah-Hartman
@ 2018-02-21 14:22               ` Boris Brezillon
  2018-02-21 14:38                 ` Greg Kroah-Hartman
  0 siblings, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2018-02-21 14:22 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec,
	Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
	Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni,
	Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
	Geert Uytterhoeven, Linus Walleij

Hi Greg,

On Tue, 19 Dec 2017 10:36:43 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Tue, Dec 19, 2017 at 10:28:58AM +0100, Boris Brezillon wrote:
> > On Tue, 19 Dec 2017 10:21:19 +0100
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >   
> > > On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote:  
> > > > On Tue, 19 Dec 2017 10:09:00 +0100
> > > > Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> > > >     
> > > > > On Tue, 19 Dec 2017 09:52:50 +0100
> > > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > > >     
> > > > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:      
> > > > > > > +/**
> > > > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> > > > > > > + * @i3cdev: the I3C device we're searching a match for
> > > > > > > + * @id_table: the I3C device ID table
> > > > > > > + *
> > > > > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> > > > > > > + *	   no match.
> > > > > > > + */
> > > > > > > +const struct i3c_device_id *
> > > > > > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > > > > > +		    const struct i3c_device_id *id_table)
> > > > > > > +{
> > > > > > > +	const struct i3c_device_id *id;
> > > > > > > +
> > > > > > > +	/*
> > > > > > > +	 * The lower 32bits of the provisional ID is just filled with a random
> > > > > > > +	 * value, try to match using DCR info.
> > > > > > > +	 */
> > > > > > > +	if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > > > > > +		u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > > > > > +		u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > > > > > +		u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > > > > > +
> > > > > > > +		/* First try to match by manufacturer/part ID. */
> > > > > > > +		for (id = id_table; id->match_flags != 0; id++) {
> > > > > > > +			if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > > > > > > +			    I3C_MATCH_MANUF_AND_PART)
> > > > > > > +				continue;
> > > > > > > +
> > > > > > > +			if (manuf != id->manuf_id || part != id->part_id)
> > > > > > > +				continue;
> > > > > > > +
> > > > > > > +			if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > > > > > +			    ext_info != id->extra_info)
> > > > > > > +				continue;
> > > > > > > +
> > > > > > > +			return id;
> > > > > > > +		}
> > > > > > > +	}
> > > > > > > +
> > > > > > > +	/* Fallback to DCR match. */
> > > > > > > +	for (id = id_table; id->match_flags != 0; id++) {
> > > > > > > +		if ((id->match_flags & I3C_MATCH_DCR) &&
> > > > > > > +		    id->dcr == i3cdev->info.dcr)
> > > > > > > +			return id;
> > > > > > > +	}
> > > > > > > +
> > > > > > > +	return NULL;
> > > > > > > +}
> > > > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);        
> > > > > > 
> > > > > > I just picked one random export here, but it feels like you are
> > > > > > exporting a bunch of symbols you don't need to.  Why would something
> > > > > > outside of the i3c "core" need to call this function?      
> > > > > 
> > > > > Because I'm not passing the i3c_device_id to the ->probe() method, and
> > > > > if the driver is supporting different variants of the device, it may
> > > > > want to know which one is being probed.
> > > > > 
> > > > > I considered retrieving this information in the core just before probing
> > > > > the driver and passing it to the ->probe() function, but it means
> > > > > having an extra i3c_device_match_id() call for everyone even those who
> > > > > don't care about the device_id information, so I thought exporting this
> > > > > function was a good alternative (device drivers can use it when they
> > > > > actually need to retrieve the device_id).
> > > > > 
> > > > > Anyway, that's something I can change if you think passing the
> > > > > i3c_device_id to the ->probe() method is preferable.
> > > > >     
> > > > > > Have you looked
> > > > > > to see if you really have callers for everything you are exporting?      
> > > > > 
> > > > > Yes, I tried to only export functions that I think will be needed by
> > > > > I3C device drivers and I3C master drivers. Note that I didn't post the
> > > > > dummy device driver I developed to test the framework (partly because
> > > > > this is     
> > > > 
> > > > Sorry, I hit the send button before finishing my sentence :-).
> > > > 
> > > > "
> > > > Note that I didn't post the dummy device driver [1] I developed to test
> > > > the framework (partly because the quality of the code does not meet
> > > > mainline standards and I was ashamed of posting it publicly :-)), but
> > > > this driver is using some of the exported functions.
> > > > "    
> > > 
> > > We don't export functions that has no in-kernel users :)  
> > 
> > But then, I can't export device driver related functions, because
> > there's no official device driver yet :-). So what should I do?  
> 
> Export them when you have a driver.  Or better yet, submit a driver as
> part of the patch series.  Why would we want infrastructure that no one
> uses?

I understand your point of view, it may sound odd to add a framework
for a bus that we have no slave devices for. But, as far as I can tell,
many vendors (both IP vendors and sensor manufacturers) are working
actively on creating master and slave I3C devices. Actually, I've even
been contacted privately by an IP vendor after posting this patchset.
So, I think one argument for pushing the current framework with no
users yet is that it may help others develop drivers for their device
early on, or even help them test those devices more easily than if they
had to develop baremetal code.

The kernel community has been asking hardware vendors for a long time to
upstream their code as early as possible. And this is exactly what is
happening with I3C: even before actual devices are shipping, we have
the opportunity to start merging support for I3C in the mainline
kernel. It would be good to merge it before vendors spend time working
on competing implementations, which will take even more time to
reconcile when they will be submitted for upstream inclusion.

Also, we're not talking about some random bus/protocol, I3C spec is
developed and pushed by MIPI, and for once, they decided to open the
spec, so anyone can actually make sure the framework is matching the
protocol description if they want to.

Now, if you still think an I3C device driver is needed to consider
merging these patches, I can provide one. As I said earlier, I
developed a driver for a dummy device to test the various features I
add support for in this series, it's just that this device will never
ever be available in real life and it's not even fitting in any of the
subsystem we have in the kernel, hence my initial decision to not
upstream it.

Regards,

Boris

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-21 14:22               ` Boris Brezillon
@ 2018-02-21 14:38                 ` Greg Kroah-Hartman
  0 siblings, 0 replies; 50+ messages in thread
From: Greg Kroah-Hartman @ 2018-02-21 14:38 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec,
	Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
	Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni,
	Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
	Geert Uytterhoeven, Linus Walleij

On Wed, Feb 21, 2018 at 03:22:48PM +0100, Boris Brezillon wrote:
> Hi Greg,
> 
> On Tue, 19 Dec 2017 10:36:43 +0100
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> > On Tue, Dec 19, 2017 at 10:28:58AM +0100, Boris Brezillon wrote:
> > > On Tue, 19 Dec 2017 10:21:19 +0100
> > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > >   
> > > > On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote:  
> > > > > On Tue, 19 Dec 2017 10:09:00 +0100
> > > > > Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> > > > >     
> > > > > > On Tue, 19 Dec 2017 09:52:50 +0100
> > > > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > > > >     
> > > > > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:      
> > > > > > > > +/**
> > > > > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> > > > > > > > + * @i3cdev: the I3C device we're searching a match for
> > > > > > > > + * @id_table: the I3C device ID table
> > > > > > > > + *
> > > > > > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> > > > > > > > + *	   no match.
> > > > > > > > + */
> > > > > > > > +const struct i3c_device_id *
> > > > > > > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > > > > > > +		    const struct i3c_device_id *id_table)
> > > > > > > > +{
> > > > > > > > +	const struct i3c_device_id *id;
> > > > > > > > +
> > > > > > > > +	/*
> > > > > > > > +	 * The lower 32bits of the provisional ID is just filled with a random
> > > > > > > > +	 * value, try to match using DCR info.
> > > > > > > > +	 */
> > > > > > > > +	if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > > > > > > +		u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > > > > > > +		u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > > > > > > +		u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > > > > > > +
> > > > > > > > +		/* First try to match by manufacturer/part ID. */
> > > > > > > > +		for (id = id_table; id->match_flags != 0; id++) {
> > > > > > > > +			if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > > > > > > > +			    I3C_MATCH_MANUF_AND_PART)
> > > > > > > > +				continue;
> > > > > > > > +
> > > > > > > > +			if (manuf != id->manuf_id || part != id->part_id)
> > > > > > > > +				continue;
> > > > > > > > +
> > > > > > > > +			if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > > > > > > +			    ext_info != id->extra_info)
> > > > > > > > +				continue;
> > > > > > > > +
> > > > > > > > +			return id;
> > > > > > > > +		}
> > > > > > > > +	}
> > > > > > > > +
> > > > > > > > +	/* Fallback to DCR match. */
> > > > > > > > +	for (id = id_table; id->match_flags != 0; id++) {
> > > > > > > > +		if ((id->match_flags & I3C_MATCH_DCR) &&
> > > > > > > > +		    id->dcr == i3cdev->info.dcr)
> > > > > > > > +			return id;
> > > > > > > > +	}
> > > > > > > > +
> > > > > > > > +	return NULL;
> > > > > > > > +}
> > > > > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);        
> > > > > > > 
> > > > > > > I just picked one random export here, but it feels like you are
> > > > > > > exporting a bunch of symbols you don't need to.  Why would something
> > > > > > > outside of the i3c "core" need to call this function?      
> > > > > > 
> > > > > > Because I'm not passing the i3c_device_id to the ->probe() method, and
> > > > > > if the driver is supporting different variants of the device, it may
> > > > > > want to know which one is being probed.
> > > > > > 
> > > > > > I considered retrieving this information in the core just before probing
> > > > > > the driver and passing it to the ->probe() function, but it means
> > > > > > having an extra i3c_device_match_id() call for everyone even those who
> > > > > > don't care about the device_id information, so I thought exporting this
> > > > > > function was a good alternative (device drivers can use it when they
> > > > > > actually need to retrieve the device_id).
> > > > > > 
> > > > > > Anyway, that's something I can change if you think passing the
> > > > > > i3c_device_id to the ->probe() method is preferable.
> > > > > >     
> > > > > > > Have you looked
> > > > > > > to see if you really have callers for everything you are exporting?      
> > > > > > 
> > > > > > Yes, I tried to only export functions that I think will be needed by
> > > > > > I3C device drivers and I3C master drivers. Note that I didn't post the
> > > > > > dummy device driver I developed to test the framework (partly because
> > > > > > this is     
> > > > > 
> > > > > Sorry, I hit the send button before finishing my sentence :-).
> > > > > 
> > > > > "
> > > > > Note that I didn't post the dummy device driver [1] I developed to test
> > > > > the framework (partly because the quality of the code does not meet
> > > > > mainline standards and I was ashamed of posting it publicly :-)), but
> > > > > this driver is using some of the exported functions.
> > > > > "    
> > > > 
> > > > We don't export functions that has no in-kernel users :)  
> > > 
> > > But then, I can't export device driver related functions, because
> > > there's no official device driver yet :-). So what should I do?  
> > 
> > Export them when you have a driver.  Or better yet, submit a driver as
> > part of the patch series.  Why would we want infrastructure that no one
> > uses?
> 
> I understand your point of view, it may sound odd to add a framework
> for a bus that we have no slave devices for. But, as far as I can tell,
> many vendors (both IP vendors and sensor manufacturers) are working
> actively on creating master and slave I3C devices. Actually, I've even
> been contacted privately by an IP vendor after posting this patchset.
> So, I think one argument for pushing the current framework with no
> users yet is that it may help others develop drivers for their device
> early on, or even help them test those devices more easily than if they
> had to develop baremetal code.
> 
> The kernel community has been asking hardware vendors for a long time to
> upstream their code as early as possible. And this is exactly what is
> happening with I3C: even before actual devices are shipping, we have
> the opportunity to start merging support for I3C in the mainline
> kernel. It would be good to merge it before vendors spend time working
> on competing implementations, which will take even more time to
> reconcile when they will be submitted for upstream inclusion.

But without real users of an api, you do not even know if it works or
not at all.  In reality, you need at least 3 users of an api to know if
it is correct.  How do you even know this works or not?

Again, we don't merge "frameworks" that no one uses.

> Also, we're not talking about some random bus/protocol, I3C spec is
> developed and pushed by MIPI, and for once, they decided to open the
> spec, so anyone can actually make sure the framework is matching the
> protocol description if they want to.

One might consider i3c any "random" bus, given that there are no devices
for it yet :)

> Now, if you still think an I3C device driver is needed to consider
> merging these patches, I can provide one. As I said earlier, I
> developed a driver for a dummy device to test the various features I
> add support for in this series, it's just that this device will never
> ever be available in real life and it's not even fitting in any of the
> subsystem we have in the kernel, hence my initial decision to not
> upstream it.

What is stopping you from working with one of those aformentioned
companies to get a driver working for their hardware?  Without that type
of testing, you don't even know if your framework is correct or not.
Dummy drivers are nice, but those are written to fit into your framework
more than they are to driver an actual device, which might require
changes to the framework.

So please, just work with those companies, get a real driver, and then
I will be glad to merge it all, driver included.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 0/7] Add the I3C subsystem
  2017-12-14 15:16 [PATCH v2 0/7] Add the I3C subsystem Boris Brezillon
                   ` (6 preceding siblings ...)
  2017-12-14 15:16 ` [PATCH v2 7/7] dt-bindings: i3c: Document Cadence I3C master bindings Boris Brezillon
@ 2018-02-22 15:00 ` Vitor Soares
  7 siblings, 0 replies; 50+ messages in thread
From: Vitor Soares @ 2018-02-22 15:00 UTC (permalink / raw)
  To: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij

Hi Boris,

We are very interested in your I3C subsystem proposal and we would like 
to colaborate with you in order to add support for the Synopsys Host 
Controller.


We are doing the review for this patch-set and will send our conclusions 
as soon as possible.


Best regards,
Vitor Soares

Às 3:16 PM de 12/14/2017, Boris Brezillon escreveu:
> This patch series is a proposal for a new I3C [1] subsystem.
>
> This infrastructure is not complete yet and will be extended over
> time.
>
> 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 still open to discussion. Please let me know if you think it's
>    worth considering an asynchronous model here
> - the bus element is a separate object and is not implicitly described
>    by the master (as done in I2C). The reason is that I want to be able
>    to handle multiple master connected to the same bus and visible to
>    Linux.
>    In this situation, we should only have one instance of the device and
>    not one per master, and sharing the bus object would be part of the
>    solution to gracefully handle this case.
>    I'm not sure if we will ever need to deal with multiple masters
>    controlling the same bus and exposed under Linux, but separating the
>    bus and master concept is pretty easy, hence the decision to do it
>    now, just in case we need it some day.
>    The other benefit of separating the bus and master concepts is that
>    master devices appear under the bus directory in sysfs.
> - 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 busses 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 in this preliminary version:
> - 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
>
> Main changes between the initial RFC and this v2 are:
> - Add a generic infrastructure to support IBIs. It's worth mentioning
>    that I tried exposing IBIs as a regular IRQs, but after several
>    attempts and a discussion with Mark Zyngier, it appeared that it was
>    not really fitting in the Linux IRQ model (the fact that you have
>    payload attached to IBIs, the fact that most of the time an IBI will
>    generate a transfer on the bus which has to be done in an atomic
>    context, ...)
>    The counterpart of this decision is the latency induced by the
>    workqueue approach, but since I don't have real use cases, I don't
>    know if this can be a problem or not.
> - Add helpers to support Hot Join
> - Add support for IBIs and Hot Join in Cadence I3C master driver
> - Address several issues in how I was using the device model
>
> I'll finish on a good news: this week the MIPI alliance opened the I3C
> spec. So everyone can now review the patches (no need to be member of
> the MIPI I3C group).
> I'll let you find the link in the doc, this way maybe I'll have reviews
> on the doc itself :-).
>
> Thanks,
>
> Boris
>
> Boris Brezillon (7):
>    i2c: Export of_i2c_get_board_info()
>    i3c: Add core I3C infrastructure
>    docs: driver-api: Add I3C documentation
>    i3c: Add sysfs ABI spec
>    dt-bindings: i3c: Document core bindings
>    i3c: master: Add driver for Cadence IP
>    dt-bindings: i3c: Document Cadence I3C master bindings
>
>   Documentation/ABI/testing/sysfs-bus-i3c            |   95 ++
>   .../devicetree/bindings/i3c/cdns,i3c-master.txt    |   45 +
>   Documentation/devicetree/bindings/i3c/i3c.txt      |  128 ++
>   Documentation/driver-api/i3c/conf.py               |   10 +
>   Documentation/driver-api/i3c/device-driver-api.rst |    7 +
>   Documentation/driver-api/i3c/index.rst             |    9 +
>   Documentation/driver-api/i3c/master-driver-api.rst |    8 +
>   Documentation/driver-api/i3c/protocol.rst          |  201 +++
>   Documentation/driver-api/index.rst                 |    1 +
>   drivers/Kconfig                                    |    2 +
>   drivers/Makefile                                   |    2 +-
>   drivers/i2c/i2c-core-base.c                        |    2 +-
>   drivers/i2c/i2c-core-of.c                          |   66 +-
>   drivers/i3c/Kconfig                                |   24 +
>   drivers/i3c/Makefile                               |    4 +
>   drivers/i3c/core.c                                 |  573 +++++++
>   drivers/i3c/device.c                               |  344 ++++
>   drivers/i3c/internals.h                            |   34 +
>   drivers/i3c/master.c                               | 1433 ++++++++++++++++
>   drivers/i3c/master/Kconfig                         |    5 +
>   drivers/i3c/master/Makefile                        |    1 +
>   drivers/i3c/master/i3c-master-cdns.c               | 1797 ++++++++++++++++++++
>   include/linux/i2c.h                                |   10 +
>   include/linux/i3c/ccc.h                            |  380 +++++
>   include/linux/i3c/device.h                         |  321 ++++
>   include/linux/i3c/master.h                         |  564 ++++++
>   include/linux/mod_devicetable.h                    |   17 +
>   27 files changed, 6053 insertions(+), 30 deletions(-)
>   create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c
>   create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
>   create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
>   create mode 100644 Documentation/driver-api/i3c/conf.py
>   create mode 100644 Documentation/driver-api/i3c/device-driver-api.rst
>   create mode 100644 Documentation/driver-api/i3c/index.rst
>   create mode 100644 Documentation/driver-api/i3c/master-driver-api.rst
>   create mode 100644 Documentation/driver-api/i3c/protocol.rst
>   create mode 100644 drivers/i3c/Kconfig
>   create mode 100644 drivers/i3c/Makefile
>   create mode 100644 drivers/i3c/core.c
>   create mode 100644 drivers/i3c/device.c
>   create mode 100644 drivers/i3c/internals.h
>   create mode 100644 drivers/i3c/master.c
>   create mode 100644 drivers/i3c/master/Kconfig
>   create mode 100644 drivers/i3c/master/Makefile
>   create mode 100644 drivers/i3c/master/i3c-master-cdns.c
>   create mode 100644 include/linux/i3c/ccc.h
>   create mode 100644 include/linux/i3c/device.h
>   create mode 100644 include/linux/i3c/master.h
>

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2017-12-14 15:16 ` [PATCH v2 2/7] i3c: Add core I3C infrastructure Boris Brezillon
  2017-12-17 22:32   ` Randy Dunlap
  2017-12-19  8:52   ` Greg Kroah-Hartman
@ 2018-02-23 16:28   ` Vitor Soares
  2018-02-23 16:56   ` Vitor Soares
  3 siblings, 0 replies; 50+ messages in thread
From: Vitor Soares @ 2018-02-23 16:28 UTC (permalink / raw)
  To: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij

[-- Attachment #1: Type: text/plain, Size: 31964 bytes --]

Hi Boris,


Às 3:16 PM de 12/14/2017, Boris Brezillon escreveu:
> +
> +enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus,
> +						       u16 addr)
> +{
> +	int status, bitpos = addr * 2;
> +
> +	if (addr > I2C_MAX_ADDR)
> +		return I3C_ADDR_SLOT_RSVD;
> +
> +	status = bus->addrslots[bitpos / BITS_PER_LONG];
> +	status >>= bitpos % BITS_PER_LONG;
> +
> +	return status & I3C_ADDR_SLOT_STATUS_MASK;
> +}
I don't understand the size of addr. The I3C only allow 7-bit addresses.

Is the addrslots used to store the addresses and its status?
> +
> +void i3c_bus_set_addr_slot_status(struct i3c_bus *bus, u16 addr,
> +				  enum i3c_addr_slot_status status)
> +{
> +	int bitpos = addr * 2;
> +	unsigned long *ptr;
> +
> +	if (addr > I2C_MAX_ADDR)
> +		return;
> +
> +	ptr = bus->addrslots + (bitpos / BITS_PER_LONG);
> +	*ptr &= ~(I3C_ADDR_SLOT_STATUS_MASK << (bitpos % BITS_PER_LONG));
> +	*ptr |= status << (bitpos % BITS_PER_LONG);
> +}
> +
> +bool i3c_bus_dev_addr_is_avail(struct i3c_bus *bus, u8 addr)
> +{
> +	enum i3c_addr_slot_status status;
> +
> +	status = i3c_bus_get_addr_slot_status(bus, addr);
> +
> +	return status == I3C_ADDR_SLOT_FREE;
> +}
> +
> +int i3c_bus_get_free_addr(struct i3c_bus *bus, u8 start_addr)
> +{
> +	enum i3c_addr_slot_status status;
> +	u8 addr;
> +
> +	for (addr = start_addr; addr < I3C_MAX_ADDR; addr++) {
> +		status = i3c_bus_get_addr_slot_status(bus, addr);
> +		if (status == I3C_ADDR_SLOT_FREE)
> +			return addr;
> +	}
> +
> +	return -ENOMEM;
> +}
> +
> +static void i3c_bus_init_addrslots(struct i3c_bus *bus)
> +{
> +	int i;
> +
> +	/* Addresses 0 to 7 are reserved. */
> +	for (i = 0; i < 8; i++)
> +		i3c_bus_set_addr_slot_status(bus, i, I3C_ADDR_SLOT_RSVD);
> +
> +	/*
> +	 * Reserve broadcast address and all addresses that might collide
> +	 * with the broadcast address when facing a single bit error.
> +	 */
> +	i3c_bus_set_addr_slot_status(bus, I3C_BROADCAST_ADDR,
> +				     I3C_ADDR_SLOT_RSVD);
> +	for (i = 0; i < 7; i++)
> +		i3c_bus_set_addr_slot_status(bus, I3C_BROADCAST_ADDR ^ BIT(i),
> +					     I3C_ADDR_SLOT_RSVD);
> +}
> +
> +static const char * const i3c_bus_mode_strings[] = {
> +	[I3C_BUS_MODE_PURE] = "pure",
> +	[I3C_BUS_MODE_MIXED_FAST] = "mixed-fast",
> +	[I3C_BUS_MODE_MIXED_SLOW] = "mixed-slow",
> +};
> +
> +static ssize_t mode_show(struct device *dev,
> +			 struct device_attribute *da,
> +			 char *buf)
> +{
> +	struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> +	ssize_t ret;
> +
> +	i3c_bus_normaluse_lock(i3cbus);
> +	if (i3cbus->mode < 0 ||
> +	    i3cbus->mode > ARRAY_SIZE(i3c_bus_mode_strings) ||
> +	    !i3c_bus_mode_strings[i3cbus->mode])
> +		ret = sprintf(buf, "unknown\n");
> +	else
> +		ret = sprintf(buf, "%s\n", i3c_bus_mode_strings[i3cbus->mode]);
> +	i3c_bus_normaluse_unlock(i3cbus);
> +
> +	return ret;
> +}
> +static DEVICE_ATTR_RO(mode);
> +
> +static ssize_t current_master_show(struct device *dev,
> +				   struct device_attribute *da,
> +				   char *buf)
> +{
> +	struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> +	ssize_t ret;
> +
> +	i3c_bus_normaluse_lock(i3cbus);
> +	ret = sprintf(buf, "%s\n", dev_name(&i3cbus->cur_master->dev));
> +	i3c_bus_normaluse_unlock(i3cbus);
> +
> +	return ret;
> +}
> +static DEVICE_ATTR_RO(current_master);
> +
> +static ssize_t i3c_scl_frequency_show(struct device *dev,
> +				      struct device_attribute *da,
> +				      char *buf)
> +{
> +	struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> +	ssize_t ret;
> +
> +	i3c_bus_normaluse_lock(i3cbus);
> +	ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i3c);
> +	i3c_bus_normaluse_unlock(i3cbus);
> +
> +	return ret;
> +}
> +static DEVICE_ATTR_RO(i3c_scl_frequency);
> +
> +static ssize_t i2c_scl_frequency_show(struct device *dev,
> +				      struct device_attribute *da,
> +				      char *buf)
> +{
> +	struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> +	ssize_t ret;
> +
> +	i3c_bus_normaluse_lock(i3cbus);
> +	ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i2c);
> +	i3c_bus_normaluse_unlock(i3cbus);
> +
> +	return ret;
> +}
> +static DEVICE_ATTR_RO(i2c_scl_frequency);
> +
> +static struct attribute *i3c_busdev_attrs[] = {
> +	&dev_attr_mode.attr,
> +	&dev_attr_current_master.attr,
> +	&dev_attr_i3c_scl_frequency.attr,
> +	&dev_attr_i2c_scl_frequency.attr,
> +	NULL,
> +};
> +ATTRIBUTE_GROUPS(i3c_busdev);
> +
> +static void i3c_busdev_release(struct device *dev)
> +{
> +	struct i3c_bus *bus = container_of(dev, struct i3c_bus, dev);
> +
> +	while (!list_empty(&bus->devs.i2c)) {
> +		struct i2c_device *i2cdev;
> +
> +		i2cdev = list_first_entry(&bus->devs.i2c, struct i2c_device,
> +					  common.node);
> +		list_del(&i2cdev->common.node);
> +		of_node_put(i2cdev->info.of_node);
> +		kfree(i2cdev);
> +	}
> +
> +	while (!list_empty(&bus->devs.i3c)) {
> +		struct i3c_device *i3cdev;
> +
> +		i3cdev = list_first_entry(&bus->devs.i3c, struct i3c_device,
> +					  common.node);
> +		list_del(&i3cdev->common.node);
> +		put_device(&i3cdev->dev);
> +	}
> +
> +	mutex_lock(&i3c_core_lock);
> +	idr_remove(&i3c_bus_idr, bus->id);
> +	mutex_unlock(&i3c_core_lock);
> +
> +	of_node_put(bus->dev.of_node);
> +	kfree(bus);
> +}
> +
> +static const struct device_type i3c_busdev_type = {
> +	.groups	= i3c_busdev_groups,
> +};
> +
> +void i3c_bus_unref(struct i3c_bus *bus)
> +{
> +	put_device(&bus->dev);
> +}
> +
> +struct i3c_bus *i3c_bus_create(struct device *parent)
> +{
> +	struct i3c_bus *i3cbus;
> +	int ret;
> +
> +	i3cbus = kzalloc(sizeof(*i3cbus), GFP_KERNEL);
> +	if (!i3cbus)
> +		return ERR_PTR(-ENOMEM);
> +
> +	init_rwsem(&i3cbus->lock);
> +	INIT_LIST_HEAD(&i3cbus->devs.i2c);
> +	INIT_LIST_HEAD(&i3cbus->devs.i3c);
> +	i3c_bus_init_addrslots(i3cbus);
> +	i3cbus->mode = I3C_BUS_MODE_PURE;
> +	i3cbus->dev.parent = parent;
> +	i3cbus->dev.of_node = of_node_get(parent->of_node);
> +	i3cbus->dev.bus = &i3c_bus_type;
> +	i3cbus->dev.type = &i3c_busdev_type;
> +	i3cbus->dev.release = i3c_busdev_release;
> +
> +	mutex_lock(&i3c_core_lock);
> +	ret = idr_alloc(&i3c_bus_idr, i3cbus, 0, 0, GFP_KERNEL);
> +	mutex_unlock(&i3c_core_lock);
> +	if (ret < 0)
> +		goto err_free_bus;
> +
> +	i3cbus->id = ret;
> +	device_initialize(&i3cbus->dev);
> +
> +	return i3cbus;
> +
> +err_free_bus:
> +	kfree(i3cbus);
> +
> +	return ERR_PTR(ret);
> +}
> +
> +void i3c_bus_unregister(struct i3c_bus *bus)
> +{
> +	device_unregister(&bus->dev);
> +}
> +
> +int i3c_bus_register(struct i3c_bus *i3cbus)
> +{
> +	struct i2c_device *i2cdev;
> +
> +	i3c_bus_for_each_i2cdev(i3cbus, i2cdev) {
> +		switch (i2cdev->lvr & I3C_LVR_I2C_INDEX_MASK) {
> +		case I3C_LVR_I2C_INDEX(0):
> +			if (i3cbus->mode < I3C_BUS_MODE_MIXED_FAST)
> +				i3cbus->mode = I3C_BUS_MODE_MIXED_FAST;
> +			break;
> +
> +		case I3C_LVR_I2C_INDEX(1):
> +		case I3C_LVR_I2C_INDEX(2):
> +			if (i3cbus->mode < I3C_BUS_MODE_MIXED_SLOW)
> +				i3cbus->mode = I3C_BUS_MODE_MIXED_SLOW;
> +			break;
> +
> +		default:
> +			return -EINVAL;
> +		}
> +	}
> +
> +	if (!i3cbus->scl_rate.i3c)
> +		i3cbus->scl_rate.i3c = I3C_BUS_TYP_I3C_SCL_RATE;
> +
> +	if (!i3cbus->scl_rate.i2c) {
> +		if (i3cbus->mode == I3C_BUS_MODE_MIXED_SLOW)
> +			i3cbus->scl_rate.i2c = I3C_BUS_I2C_FM_SCL_RATE;
> +		else
> +			i3cbus->scl_rate.i2c = I3C_BUS_I2C_FM_PLUS_SCL_RATE;
> +	}
> +
> +	/*
> +	 * I3C/I2C frequency may have been overridden, check that user-provided
> +	 * values are not exceeding max possible frequency.
> +	 */
> +	if (i3cbus->scl_rate.i3c > I3C_BUS_MAX_I3C_SCL_RATE ||
> +	    i3cbus->scl_rate.i2c > I3C_BUS_I2C_FM_PLUS_SCL_RATE) {
> +		return -EINVAL;
> +	}
> +
> +	dev_set_name(&i3cbus->dev, "i3c-%d", i3cbus->id);
> +
> +	return device_add(&i3cbus->dev);
> +}
> +
> +static int __init i3c_init(void)
> +{
> +	return bus_register(&i3c_bus_type);
> +}
> +subsys_initcall(i3c_init);
> +
> +static void __exit i3c_exit(void)
> +{
> +	idr_destroy(&i3c_bus_idr);
> +	bus_unregister(&i3c_bus_type);
> +}
> +module_exit(i3c_exit);
> +
> +MODULE_AUTHOR("Boris Brezillon<boris.brezillon@free-electrons.com>");
> +MODULE_DESCRIPTION("I3C core");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/i3c/device.c b/drivers/i3c/device.c
> new file mode 100644
> index 000000000000..dcf51150b7cb
> --- /dev/null
> +++ b/drivers/i3c/device.c
> @@ -0,0 +1,344 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> + */
> +
> +#include <linux/slab.h>
> +
> +#include "internals.h"
> +
> +/**
> + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a
> + *				specific device
> + *
> + * @dev: device with which the transfers should be done
> + * @xfers: array of transfers
> + * @nxfers: number of transfers
> + *
> + * Initiate one or several private SDR transfers with @dev.
> + *
> + * This function can sleep and thus cannot be called in atomic context.
> + *
> + * Return: 0 in case of success, a negative error core otherwise.
> + */
> +int i3c_device_do_priv_xfers(struct i3c_device *dev,
> +			     struct i3c_priv_xfer *xfers,
> +			     int nxfers)
> +{
> +	struct i3c_master_controller *master;
> +	int i, ret;
> +
> +	master = i3c_device_get_master(dev);
> +	if (!master)
> +		return -EINVAL;
> +
> +	i3c_bus_normaluse_lock(master->bus);
> +	for (i = 0; i < nxfers; i++)
> +		xfers[i].addr = dev->info.dyn_addr;
> +
> +	ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
> +	i3c_bus_normaluse_unlock(master->bus);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);
The controller should know the speed mode for each xfer. The SDR0 mode 
is used by default but if any device have read or write speed 
limitations the controller can use SDRx.

This could be also applied to i2c transfers.
> +#endif /* I3C_INTERNAL_H */
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> new file mode 100644
> index 000000000000..1c85abac08d5
> --- /dev/null
> +++ b/drivers/i3c/master.c
> @@ -0,0 +1,1433 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> + */
> +
> +#include <linux/slab.h>
> +
> +#include "internals.h"
> +
> +/**
> + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
> + *				procedure
> + * @master: master used to send frames on the bus
> + *
> + * Send a ENTDAA CCC command to start a DAA procedure.
> + *
> + * Note that this function only sends the ENTDAA CCC command, all the logic
> + * behind dynamic address assignment has to be handled in the I3C master
> + * driver.
> + *
> + * This function must be called with the bus lock held in write mode.
> + *
> + * Return: 0 in case of success, a negative error code otherwise.
> + */
> +int i3c_master_entdaa_locked(struct i3c_master_controller *master)
> +{
> +	struct i3c_ccc_cmd_dest dest = { };
> +	struct i3c_ccc_cmd cmd = { };
> +	int ret;
> +
> +	dest.addr = I3C_BROADCAST_ADDR;
> +	cmd.dests = &dest;
> +	cmd.ndests = 1;
> +	cmd.rnw = false;
> +	cmd.id = I3C_CCC_ENTDAA;
> +
> +	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked);
can you explain the process?  the command is only execute once, what if 
there is more devices on the bus?
> +
> +/**
> + * i3c_master_defslvs_locked() - send a DEFSLVS CCC command
> + * @master: master used to send frames on the bus
> + *
> + * Send a DEFSLVS CCC command containing all the devices known to the @master.
> + * This is useful when you have secondary masters on the bus to propagate
> + * device information.
> + *
> + * This should be called after all I3C devices have been discovered (in other
> + * words, after the DAA procedure has finished) and instantiated in
> + * i3c_master_controller_ops->bus_init().
> + * It should also be called if a master ACKed an Hot-Join request and assigned
> + * a dynamic address to the device joining the bus.
> + *
> + * This function must be called with the bus lock held in write mode.
> + *
> + * Return: 0 in case of success, a negative error code otherwise.
> + */
> +int i3c_master_defslvs_locked(struct i3c_master_controller *master)
> +{
> +	struct i3c_ccc_cmd_dest dest = {
> +		.addr = I3C_BROADCAST_ADDR,
> +	};
> +	struct i3c_ccc_cmd cmd = {
> +		.id = I3C_CCC_DEFSLVS,
> +		.dests = &dest,
> +		.ndests = 1,
> +	};
> +	struct i3c_ccc_defslvs *defslvs;
> +	struct i3c_ccc_dev_desc *desc;
> +	struct i3c_device *i3cdev;
> +	struct i2c_device *i2cdev;
> +	struct i3c_bus *bus;
> +	bool send = false;
> +	int ndevs = 0, ret;
> +
> +	if (!master)
> +		return -EINVAL;
> +
> +	bus = i3c_master_get_bus(master);
> +	i3c_bus_for_each_i3cdev(bus, i3cdev) {
> +		ndevs++;
> +		if (I3C_BCR_DEVICE_ROLE(i3cdev->info.bcr) == I3C_BCR_I3C_MASTER)
> +			send = true;
> +	}
> +
> +	/* No other master on the bus, skip DEFSLVS. */
> +	if (!send)
> +		return 0;
> +
> +	i3c_bus_for_each_i2cdev(bus, i2cdev)
> +		ndevs++;
> +
> +	dest.payload.len = sizeof(*defslvs) +
> +			   ((ndevs - 1) * sizeof(struct i3c_ccc_dev_desc));
> +	defslvs = kzalloc(dest.payload.len, GFP_KERNEL);
> +	if (!defslvs)
> +		return -ENOMEM;
> +
> +	dest.payload.data = defslvs;
> +
> +	defslvs->count = ndevs;
> +	defslvs->master.bcr = master->this->info.bcr;
> +	defslvs->master.dcr = master->this->info.dcr;
> +	defslvs->master.dyn_addr = master->this->info.dyn_addr;
> +	defslvs->master.static_addr = I3C_BROADCAST_ADDR;
Why defslvs->master.static_addr = I3C_BROADCAST_ADDR?
> +
> +	desc = defslvs->slaves;
> +	i3c_bus_for_each_i2cdev(bus, i2cdev) {
> +		desc->lvr = i2cdev->lvr;
> +		desc->static_addr = i2cdev->info.addr;
> +		desc++;
> +	}
> +
> +	i3c_bus_for_each_i3cdev(bus, i3cdev) {
> +		/* Skip the I3C dev representing this master. */
> +		if (i3cdev == master->this)
> +			continue;
> +
> +		desc->bcr = i3cdev->info.bcr;
> +		desc->dcr = i3cdev->info.dcr;
> +		desc->dyn_addr = i3cdev->info.dyn_addr;
> +		desc->static_addr = i3cdev->info.static_addr;
> +		desc++;
> +	}
> +
> +	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
> +	kfree(defslvs);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(i3c_master_defslvs_locked);
> +
>
>
>
>
> +
> +static int i3c_master_i2c_adapter_xfer(struct i2c_adapter *adap,
> +				       struct i2c_msg *xfers, int nxfers)
> +{
> +	struct i3c_master_controller *master = i2c_adapter_to_i3c_master(adap);
> +	int i, ret;
> +
> +	for (i = 0; i < nxfers; i++) {
> +		enum i3c_addr_slot_status status;
> +
> +		status = i3c_bus_get_addr_slot_status(master->bus,
> +						      xfers[i].addr);
> +		if (status != I3C_ADDR_SLOT_I2C_DEV)
> +			return -EINVAL;
> +	}
> +
> +	ret = i3c_master_do_i2c_xfers(master, xfers, nxfers);
> +	if (ret)
> +		return ret;
> +
> +	return nxfers;
> +}
> +
> +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap)
> +{
> +	return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR;
> +}
Is I2C_FUNC_10BIT_ADDR allowed ?
> diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
> new file mode 100644
> index 000000000000..e69de29bb2d1
> diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
> new file mode 100644
> index 000000000000..e69de29bb2d1
> diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h
> new file mode 100644
> index 000000000000..ff3e1a3e2c4c
> --- /dev/null
> +++ b/include/linux/i3c/ccc.h
> @@ -0,0 +1,380 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> + */
> +
> +
> +/**
> + * enum i3c_ccc_test_mode - enum listing all available test modes
> + *
> + * @I3C_CCC_EXIT_TEST_MODE: exit test mode
> + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode
> + */
> +enum i3c_ccc_test_mode {
> +	I3C_CCC_EXIT_TEST_MODE,
> +	I3C_CCC_VENDOR_TEST_MODE,
> +};
> +
> +/**
> + * struct i3c_ccc_enttm - payload passed to ENTTM CCC
> + *
> + * @mode: one of the &enum i3c_ccc_test_mode modes
> + *
> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
> + * specific test mode.
> + */
> +struct i3c_ccc_enttm {
> +	u8 mode;
> +} __packed;
> +
> +/**
> + * struct i3c_ccc_setda - payload passed to ENTTM CCC
> + *
> + * @mode: one of the &enum i3c_ccc_test_mode modes
> + *
> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
> + * specific test mode.
> + */
> +struct i3c_ccc_setda {
> +	u8 addr;
> +} __packed;
what do you mean with struct? Maybe setdasa? if so, what is the addr?
> +/**
> + * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers
> + */
> +enum i3c_sdr_max_data_rate {
> +	I3C_SDR_DR_FSCL_MAX,
> +	I3C_SDR_DR_FSCL_8MHZ,
> +	I3C_SDR_DR_FSCL_6MHZ,
> +	I3C_SDR_DR_FSCL_4MHZ,
> +	I3C_SDR_DR_FSCL_2MHZ,
> +};
Can you change the names to:

I3C_SDR0_FSCL_MAX,
I3C_SDR1_FSCL_8MHZ,
I3C_SDR2_FSCL_6MHZ,
I3C_SDR3_FSCL_4MHZ,
I3C_SDR4_FSCL_2MHZ,

thus the data rate isn't repeated.

> +
> +/**
> + * enum i3c_tsco - clock to data turn-around
> + */
> +enum i3c_tsco {
> +	I3C_TSCO_LT_8NS,
> +	I3C_TSCO_LT_9NS,
> +	I3C_TSCO_LT_10NS,
> +	I3C_TSCO_LT_11NS,
> +	I3C_TSCO_LT_12NS,
> +};
what's the meaning of _LT_ ?
> +
> +#endif /* I3C_CCC_H */
> diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h
> new file mode 100644
> index 000000000000..83958d3a02e2
> --- /dev/null
> +++ b/include/linux/i3c/device.h
> @@ -0,0 +1,321 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> + */
> +
> +#ifndef I3C_DEV_H
> +#define I3C_DEV_H
> +
> +#include <linux/device.h>
> +#include <linux/i2c.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +
> +/**
> + * enum i3c_hdr_mode - HDR mode ids
> + * @I3C_HDR_DDR: DDR mode
> + * @I3C_HDR_TSP: TSP mode
> + * @I3C_HDR_TSL: TSL mode
> + */
> +enum i3c_hdr_mode {
> +	I3C_HDR_DDR,
> +	I3C_HDR_TSP,
> +	I3C_HDR_TSL,
> +};
> +
> +/**
> + * struct i3c_hdr_cmd - I3C HDR command
> + * @mode: HDR mode selected for this command
> + * @code: command opcode
> + * @addr: I3C dynamic address
> + * @ndatawords: number of data words (a word is 16bits wide)
> + * @data: input/output buffer
> + */
> +struct i3c_hdr_cmd {
> +	enum i3c_hdr_mode mode;
> +	u8 code;
> +	u8 addr;
> +	int ndatawords;
> +	union {
> +		u16 *in;
> +		const u16 *out;
> +	} data;
> +};
> +
> +/* Private SDR read transfer */
> +#define I3C_PRIV_XFER_READ		BIT(0)
> +/*
> + * Instruct the controller to issue a STOP after a specific transfer instead
> + * of a REPEATED START.
> + */
> +#define I3C_PRIV_XFER_STOP		BIT(1)
> +
> +/**
> + * struct i3c_priv_xfer - I3C SDR private transfer
> + * @addr: I3C dynamic address
> + * @len: transfer length in bytes of the transfer
> + * @flags: combination of I3C_PRIV_XFER_xxx flags
> + * @data: input/output buffer
> + */
> +struct i3c_priv_xfer {
> +	u8 addr;
> +	u16 len;
> +	u32 flags;
> +	struct {
> +		void *in;
> +		const void *out;
> +	} data;
> +};
Same as above, i3c_sdr_max_data_rate to change the bus scl.
> +
> +/**
> + * enum i3c_dcr - I3C DCR values
> + * @I3C_DCR_GENERIC_DEVICE: generic I3C device
> + */
> +enum i3c_dcr {
> +	I3C_DCR_GENERIC_DEVICE = 0,
> +};
> +
> +#define I3C_PID_MANUF_ID(pid)		(((pid) & GENMASK_ULL(47, 33)) >> 33)
> +#define I3C_PID_RND_LOWER_32BITS(pid)	(!!((pid) & BIT_ULL(32)))
> +#define I3C_PID_RND_VAL(pid)		((pid) & GENMASK_ULL(31, 0))
> +#define I3C_PID_PART_ID(pid)		(((pid) & GENMASK_ULL(31, 16)) >> 16)
> +#define I3C_PID_INSTANCE_ID(pid)	(((pid) & GENMASK_ULL(15, 12)) >> 12)
> +#define I3C_PID_EXTRA_INFO(pid)		((pid) & GENMASK_ULL(11, 0))
> +
> +#define I3C_BCR_DEVICE_ROLE(bcr)	((bcr) & GENMASK(7, 6))
> +#define I3C_BCR_I3C_SLAVE		(0 << 6)
> +#define I3C_BCR_I3C_MASTER		(1 << 6)
> +#define I3C_BCR_HDR_CAP			BIT(5)
> +#define I3C_BCR_BRIDGE			BIT(4)
> +#define I3C_BCR_OFFLINE_CAP		BIT(3)
> +#define I3C_BCR_IBI_PAYLOAD		BIT(2)
> +#define I3C_BCR_IBI_REQ_CAP		BIT(1)
> +#define I3C_BCR_MAX_DATA_SPEED_LIM	BIT(0)
> +
> +/**
> + * struct i3c_device_info - I3C device information
> + * @pid: Provisional ID
> + * @bcr: Bus Characteristic Register
> + * @dcr: Device Characteristic Register
> + * @static_addr: static/I2C address
> + * @dyn_addr: dynamic address
> + * @hdr_cap: supported HDR modes
> + * @max_read_ds: max read speed information
> + * @max_write_ds: max write speed information
> + * @max_ibi_len: max IBI payload length
> + * @max_read_turnaround: max read turn-around time in micro-seconds
> + * @max_read_len: max private SDR read length in bytes
> + * @max_write_len: max private SDR write length in bytes
> + *
> + * These are all basic information that should be advertised by an I3C device.
> + * Some of them are optional depending on the device type and device
> + * capabilities.
> + * For each I3C slave attached to a master with
> + * i3c_master_add_i3c_dev_locked(), the core will send the relevant CCC command
> + * to retrieve these data.
> + */
> +struct i3c_device_info {
> +	u64 pid;
> +	u8 bcr;
> +	u8 dcr;
> +	u8 static_addr;
> +	u8 dyn_addr;
> +	u8 hdr_cap;
> +	u8 max_read_ds;
> +	u8 max_write_ds;
> +	u8 max_ibi_len;
> +	u32 max_read_turnaround;
> +	u16 max_read_len;
> +	u16 max_write_len;
> +};
> +
is this information filled with data provided from CCC commands?
> +
> +#endif /* I3C_DEV_H */
> diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
> new file mode 100644
> index 000000000000..7ec9a4821bac
> --- /dev/null
> +++ b/include/linux/i3c/master.h
> @@ -0,0 +1,564 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> + */
> +
> +#ifndef I3C_MASTER_H
> +#define I3C_MASTER_H
> +
> +#include <linux/i2c.h>
> +#include <linux/i3c/ccc.h>
> +#include <linux/i3c/device.h>
> +#include <linux/spinlock.h>
> +
> +#define I3C_HOT_JOIN_ADDR		0x2
> +#define I3C_BROADCAST_ADDR		0x7e
> +#define I3C_MAX_ADDR			GENMASK(6, 0)
> +
> +struct i3c_master_controller;
> +struct i3c_bus;
> +
> +/**
> + * struct i3c_i2c_dev - I3C/I2C common information
> + * @node: node element used to insert the device into the I2C or I3C device
> + *	  list
> + * @bus: I3C bus this device is connected to
> + * @master: I3C master that instantiated this device. Will be used to send
> + *	    I2C/I3C frames on the bus
> + * @master_priv: master private data assigned to the device. Can be used to
> + *		 add master specific information
> + *
> + * This structure is describing common I3C/I2C dev information.
> + */
> +struct i3c_i2c_dev {
> +	struct list_head node;
> +	struct i3c_bus *bus;
> +	struct i3c_master_controller *master;
> +	void *master_priv;
> +};
> +
> +#define I3C_LVR_I2C_INDEX_MASK		GENMASK(7, 5)
> +#define I3C_LVR_I2C_INDEX(x)		((x) << 5)
> +#define I3C_LVR_I2C_FM_MODE		BIT(4)
> +
> +#define I2C_MAX_ADDR			GENMASK(9, 0)
why 10-bit address?
> +
> +/**
> + * struct i2c_device - I2C device object
> + * @common: inherit common I3C/I2C description
> + * @info: I2C board info used to instantiate the I2C device. If you are
> + *	  using DT to describe your hardware, this will be filled for you
> + * @client: I2C client object created by the I2C framework. This will only
> + *	    be valid after i3c_master_register() returns
> + * @lvr: Legacy Virtual Register value as described in the I3C specification
> + *
> + * I2C device object. Note that the real I2C device is represented by
> + * i2c_device->client, but we need extra information to handle the device when
> + * it's connected to an I3C bus, hence the &struct i2c_device wrapper.
> + *
> + * The I2C framework is not impacted by this new representation.
> + */
> +struct i2c_device {
> +	struct i3c_i2c_dev common;
> +	struct i2c_board_info info;
> +	struct i2c_client *client;
> +	u8 lvr;
> +};
> +
It is usefull to know the speed limitations of the device.
> +
> +/**
> + * enum i3c_addr_slot_status - I3C address slot status
> + * @I3C_ADDR_SLOT_FREE: address is free
> + * @I3C_ADDR_SLOT_RSVD: address is reserved
> + * @I3C_ADDR_SLOT_I2C_DEV: address is assigned to an I2C device
> + * @I3C_ADDR_SLOT_I3C_DEV: address is assigned to an I3C device
> + * @I3C_ADDR_SLOT_STATUS_MASK: address slot mask
> + *
> + * On an I3C bus, addresses are assigned dynamically, and we need to know which
> + * addresses are free to use and which ones are already assigned.
> + *
> + * Addresses marked as reserved are those reserved by the I3C protocol
> + * (broadcast address, ...).
> + */
> +enum i3c_addr_slot_status {
> +	I3C_ADDR_SLOT_FREE,
> +	I3C_ADDR_SLOT_RSVD,
> +	I3C_ADDR_SLOT_I2C_DEV,
> +	I3C_ADDR_SLOT_I3C_DEV,
> +	I3C_ADDR_SLOT_STATUS_MASK = 3,
> +};
> +
> +/**
> + * struct i3c_bus - I3C bus object
> + * @dev: device to be registered to the device-model
> + * @cur_master: I3C master currently driving the bus. Since I3C is multi-master
> + *		this can change over the time. Will be used to let a master
> + *		know whether it needs to request bus ownership before sending
> + *		a frame or not
> + * @id: bus ID. Assigned by the framework when register the bus
> + * @addrslots: a bitmap with 2-bits per-slot to encode the address status and
> + *	       ease the DAA (Dynamic Address Assignment) procedure (see
> + *	       &enum i3c_addr_slot_status)
> + * @mode: bus mode (see &enum i3c_bus_mode)
> + * @scl_rate: SCL signal rate for I3C and I2C mode
> + * @devs: 2 lists containing all I3C/I2C devices connected to the bus
> + * @lock: read/write lock on the bus. This is needed to protect against
> + *	  operations that have an impact on the whole bus and the devices
> + *	  connected to it. For example, when asking slaves to drop their
> + *	  dynamic address (RSTDAA CCC), we need to make sure no one is trying
> + *	  to send I3C frames to these devices.
> + *	  Note that this lock does not protect against concurrency between
> + *	  devices: several drivers can send different I3C/I2C frames through
> + *	  the same master in parallel. This is the responsibility of the
> + *	  master to guarantee that frames are actually sent sequentially and
> + *	  not interlaced
> + *
> + * The I3C bus is represented with its own object and not implicitly described
> + * by the I3C master to cope with the multi-master functionality, where one bus
> + * can be shared amongst several masters, each of them requesting bus ownership
> + * when they need to.
> + */
> +struct i3c_bus {
> +	struct device dev;
> +	struct i3c_device *cur_master;
> +	int id;
> +	unsigned long addrslots[((I2C_MAX_ADDR + 1) * 2) / BITS_PER_LONG];
> +	enum i3c_bus_mode mode;
> +	struct {
> +		unsigned long i3c;
> +		unsigned long i2c;
> +	} scl_rate;
> +	struct {
> +		struct list_head i3c;
> +		struct list_head i2c;
> +	} devs;
> +	struct rw_semaphore lock;
> +};
Can you explain the addrslots[] ?
> +
> +static inline struct i3c_device *dev_to_i3cdev(struct device *dev)
> +{
> +	return container_of(dev, struct i3c_device, dev);
> +}
> +
> +struct i3c_master_controller;
> +
> +/**
> + * struct i3c_master_controller_ops - I3C master methods
> + * @bus_init: hook responsible for the I3C bus initialization. This
> + *	      initialization should follow the steps described in the I3C
> + *	      specification. This hook is called with the bus lock held in
> + *	      write mode, which means all _locked() helpers can safely be
> + *	      called from there
> + * @bus_cleanup: cleanup everything done in
> + *		 &i3c_master_controller_ops->bus_init(). This function is
> + *		 optional and should only be implemented if
> + *		 &i3c_master_controller_ops->bus_init() attached private data
> + *		 to I3C/I2C devices. This hook is called with the bus lock
> + *		 held in write mode, which means all _locked() helpers can
> + *		 safely be called from there
> + * @supports_ccc_cmd: should return true if the CCC command is supported, false
> + *		      otherwise
> + * @send_ccc_cmd: send a CCC command
> + * @send_hdr_cmds: send one or several HDR commands. If there is more than one
> + *		   command, they should ideally be sent in the same HDR
> + *		   transaction
> + * @priv_xfers: do one or several private I3C SDR transfers
> + * @i2c_xfers: do one or several I2C transfers
> + * @request_ibi: attach an IBI handler to an I3C device. This implies defining
> + *		 an IBI handler and the constraints of the IBI (maximum payload
> + *		 length and number of pre-allocated slots).
> + *		 Some controllers support less IBI-capable devices than regular
> + *		 devices, so this method might return -%EBUSY if there's no
> + *		 more space for an extra IBI registration
> + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI
> + *	      should have been disabled with ->disable_irq() prior to that
> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called
> + *		prior to ->enable_ibi(). The controller should first enable
> + *		the IBI on the controller end (for example, unmask the hardware
> + *		IRQ) and then send the ENEC CCC command (with the IBI flag set)
> + *		to the I3C device
> + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI
> + *		 flag set and then deactivate the hardware IRQ on the
> + *		 controller end
> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been
> + *		      processed by its handler. The IBI slot should be put back
> + *		      in the IBI slot pool so that the controller can re-use it
> + *		      for a future IBI
> + *
> + * One of the most important hooks in these ops is
> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of
> + * things that should be done in &i3c_master_controller_ops->bus_init():
> + *
> + * 1) call i3c_master_set_info() with all information describing the master
> + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC
> + *    with i3c_master_rstdaa_locked()
> + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked()
> + * 4) start a DDA procedure by sending the ENTDAA CCC with
> + *    i3c_master_entdaa_locked(), or using the internal DAA logic provided by
> + *    your controller
You mean SETDASA CCC command?
> + * 5) assign a dynamic address to each I3C device discovered during DAA and
> + *    for each of them, call i3c_master_add_i3c_dev_locked()
> + * 6) propagate device table to secondary masters by calling
> + *    i3c_master_defslvs_locked()
> + *
> + * Note that these steps do not include all controller specific initialization.
> + */
> +struct i3c_master_controller_ops {
> +	int (*bus_init)(struct i3c_master_controller *master);
> +	void (*bus_cleanup)(struct i3c_master_controller *master);
> +	bool (*supports_ccc_cmd)(struct i3c_master_controller *master,
> +				 const struct i3c_ccc_cmd *cmd);
> +	int (*send_ccc_cmd)(struct i3c_master_controller *master,
> +			    struct i3c_ccc_cmd *cmd);
> +	int (*send_hdr_cmds)(struct i3c_master_controller *master,
> +			     const struct i3c_hdr_cmd *cmds,
> +			     int ncmds);
> +	int (*priv_xfers)(struct i3c_master_controller *master,
> +			  const struct i3c_priv_xfer *xfers,
> +			  int nxfers);
> +	int (*i2c_xfers)(struct i3c_master_controller *master,
> +			 const struct i2c_msg *xfers, int nxfers);
> +	int (*request_ibi)(struct i3c_master_controller *master,
> +			   struct i3c_device *dev,
> +			   const struct i3c_ibi_setup *req);
> +	void (*free_ibi)(struct i3c_master_controller *master,
> +			 struct i3c_device *dev);
> +	int (*enable_ibi)(struct i3c_master_controller *master,
> +			  struct i3c_device *dev);
> +	int (*disable_ibi)(struct i3c_master_controller *master,
> +			   struct i3c_device *dev);
> +	void (*recycle_ibi_slot)(struct i3c_master_controller *master,
> +				 struct i3c_device *dev,
> +				 struct i3c_ibi_slot *slot);
> +};
> +
>

Best regards,
Vitor Soares

[-- Attachment #2: Type: text/html, Size: 33856 bytes --]

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2017-12-14 15:16 ` [PATCH v2 2/7] i3c: Add core I3C infrastructure Boris Brezillon
                     ` (2 preceding siblings ...)
  2018-02-23 16:28   ` Vitor Soares
@ 2018-02-23 16:56   ` Vitor Soares
  2018-02-23 20:30     ` Boris Brezillon
  2018-02-23 22:45     ` Boris Brezillon
  3 siblings, 2 replies; 50+ messages in thread
From: Vitor Soares @ 2018-02-23 16:56 UTC (permalink / raw)
  To: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann
  Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
	Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
	Suresh Punnoose, Thomas Petazzoni, Nishanth Menon, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
	linux-kernel, Vitor Soares, Geert Uytterhoeven, Linus Walleij

Hi Boris,

Às 3:16 PM de 12/14/2017, Boris Brezillon escreveu:
> +
> +enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus,
> +						       u16 addr)
> +{
> +	int status, bitpos = addr * 2;
> +
> +	if (addr > I2C_MAX_ADDR)
> +		return I3C_ADDR_SLOT_RSVD;
> +
> +	status = bus->addrslots[bitpos / BITS_PER_LONG];
> +	status >>= bitpos % BITS_PER_LONG;
> +
> +	return status & I3C_ADDR_SLOT_STATUS_MASK;
> +}

I don't understand the size of addr. The I3C only allow 7-bit addresses.

Is the addrslots used to store the addresses and its status?

> +
> +void i3c_bus_set_addr_slot_status(struct i3c_bus *bus, u16 addr,
> +				  enum i3c_addr_slot_status status)
> +{
> +	int bitpos = addr * 2;
> +	unsigned long *ptr;
> +
> +	if (addr > I2C_MAX_ADDR)
> +		return;
> +
> +	ptr = bus->addrslots + (bitpos / BITS_PER_LONG);
> +	*ptr &= ~(I3C_ADDR_SLOT_STATUS_MASK << (bitpos % BITS_PER_LONG));
> +	*ptr |= status << (bitpos % BITS_PER_LONG);
> +}
> +
> +bool i3c_bus_dev_addr_is_avail(struct i3c_bus *bus, u8 addr)
> +{
> +	enum i3c_addr_slot_status status;
> +
> +	status = i3c_bus_get_addr_slot_status(bus, addr);
> +
> +	return status == I3C_ADDR_SLOT_FREE;
> +}
> +
> +int i3c_bus_get_free_addr(struct i3c_bus *bus, u8 start_addr)
> +{
> +	enum i3c_addr_slot_status status;
> +	u8 addr;
> +
> +	for (addr = start_addr; addr < I3C_MAX_ADDR; addr++) {
> +		status = i3c_bus_get_addr_slot_status(bus, addr);
> +		if (status == I3C_ADDR_SLOT_FREE)
> +			return addr;
> +	}
> +
> +	return -ENOMEM;
> +}
> +
> +static void i3c_bus_init_addrslots(struct i3c_bus *bus)
> +{
> +	int i;
> +
> +	/* Addresses 0 to 7 are reserved. */
> +	for (i = 0; i < 8; i++)
> +		i3c_bus_set_addr_slot_status(bus, i, I3C_ADDR_SLOT_RSVD);
> +
> +	/*
> +	 * Reserve broadcast address and all addresses that might collide
> +	 * with the broadcast address when facing a single bit error.
> +	 */
> +	i3c_bus_set_addr_slot_status(bus, I3C_BROADCAST_ADDR,
> +				     I3C_ADDR_SLOT_RSVD);
> +	for (i = 0; i < 7; i++)
> +		i3c_bus_set_addr_slot_status(bus, I3C_BROADCAST_ADDR ^ BIT(i),
> +					     I3C_ADDR_SLOT_RSVD);
> +}
> +
> +static const char * const i3c_bus_mode_strings[] = {
> +	[I3C_BUS_MODE_PURE] = "pure",
> +	[I3C_BUS_MODE_MIXED_FAST] = "mixed-fast",
> +	[I3C_BUS_MODE_MIXED_SLOW] = "mixed-slow",
> +};
> +
> +static ssize_t mode_show(struct device *dev,
> +			 struct device_attribute *da,
> +			 char *buf)
> +{
> +	struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> +	ssize_t ret;
> +
> +	i3c_bus_normaluse_lock(i3cbus);
> +	if (i3cbus->mode < 0 ||
> +	    i3cbus->mode > ARRAY_SIZE(i3c_bus_mode_strings) ||
> +	    !i3c_bus_mode_strings[i3cbus->mode])
> +		ret = sprintf(buf, "unknown\n");
> +	else
> +		ret = sprintf(buf, "%s\n", i3c_bus_mode_strings[i3cbus->mode]);
> +	i3c_bus_normaluse_unlock(i3cbus);
> +
> +	return ret;
> +}
> +static DEVICE_ATTR_RO(mode);
> +
> +static ssize_t current_master_show(struct device *dev,
> +				   struct device_attribute *da,
> +				   char *buf)
> +{
> +	struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> +	ssize_t ret;
> +
> +	i3c_bus_normaluse_lock(i3cbus);
> +	ret = sprintf(buf, "%s\n", dev_name(&i3cbus->cur_master->dev));
> +	i3c_bus_normaluse_unlock(i3cbus);
> +
> +	return ret;
> +}
> +static DEVICE_ATTR_RO(current_master);
> +
> +static ssize_t i3c_scl_frequency_show(struct device *dev,
> +				      struct device_attribute *da,
> +				      char *buf)
> +{
> +	struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> +	ssize_t ret;
> +
> +	i3c_bus_normaluse_lock(i3cbus);
> +	ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i3c);
> +	i3c_bus_normaluse_unlock(i3cbus);
> +
> +	return ret;
> +}
> +static DEVICE_ATTR_RO(i3c_scl_frequency);
> +
> +static ssize_t i2c_scl_frequency_show(struct device *dev,
> +				      struct device_attribute *da,
> +				      char *buf)
> +{
> +	struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> +	ssize_t ret;
> +
> +	i3c_bus_normaluse_lock(i3cbus);
> +	ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i2c);
> +	i3c_bus_normaluse_unlock(i3cbus);
> +
> +	return ret;
> +}
> +static DEVICE_ATTR_RO(i2c_scl_frequency);
> +
> +static struct attribute *i3c_busdev_attrs[] = {
> +	&dev_attr_mode.attr,
> +	&dev_attr_current_master.attr,
> +	&dev_attr_i3c_scl_frequency.attr,
> +	&dev_attr_i2c_scl_frequency.attr,
> +	NULL,
> +};
> +ATTRIBUTE_GROUPS(i3c_busdev);
> +
> +static void i3c_busdev_release(struct device *dev)
> +{
> +	struct i3c_bus *bus = container_of(dev, struct i3c_bus, dev);
> +
> +	while (!list_empty(&bus->devs.i2c)) {
> +		struct i2c_device *i2cdev;
> +
> +		i2cdev = list_first_entry(&bus->devs.i2c, struct i2c_device,
> +					  common.node);
> +		list_del(&i2cdev->common.node);
> +		of_node_put(i2cdev->info.of_node);
> +		kfree(i2cdev);
> +	}
> +
> +	while (!list_empty(&bus->devs.i3c)) {
> +		struct i3c_device *i3cdev;
> +
> +		i3cdev = list_first_entry(&bus->devs.i3c, struct i3c_device,
> +					  common.node);
> +		list_del(&i3cdev->common.node);
> +		put_device(&i3cdev->dev);
> +	}
> +
> +	mutex_lock(&i3c_core_lock);
> +	idr_remove(&i3c_bus_idr, bus->id);
> +	mutex_unlock(&i3c_core_lock);
> +
> +	of_node_put(bus->dev.of_node);
> +	kfree(bus);
> +}
> +
> +static const struct device_type i3c_busdev_type = {
> +	.groups	= i3c_busdev_groups,
> +};
> +
> +void i3c_bus_unref(struct i3c_bus *bus)
> +{
> +	put_device(&bus->dev);
> +}
> +
> +struct i3c_bus *i3c_bus_create(struct device *parent)
> +{
> +	struct i3c_bus *i3cbus;
> +	int ret;
> +
> +	i3cbus = kzalloc(sizeof(*i3cbus), GFP_KERNEL);
> +	if (!i3cbus)
> +		return ERR_PTR(-ENOMEM);
> +
> +	init_rwsem(&i3cbus->lock);
> +	INIT_LIST_HEAD(&i3cbus->devs.i2c);
> +	INIT_LIST_HEAD(&i3cbus->devs.i3c);
> +	i3c_bus_init_addrslots(i3cbus);
> +	i3cbus->mode = I3C_BUS_MODE_PURE;
> +	i3cbus->dev.parent = parent;
> +	i3cbus->dev.of_node = of_node_get(parent->of_node);
> +	i3cbus->dev.bus = &i3c_bus_type;
> +	i3cbus->dev.type = &i3c_busdev_type;
> +	i3cbus->dev.release = i3c_busdev_release;
> +
> +	mutex_lock(&i3c_core_lock);
> +	ret = idr_alloc(&i3c_bus_idr, i3cbus, 0, 0, GFP_KERNEL);
> +	mutex_unlock(&i3c_core_lock);
> +	if (ret < 0)
> +		goto err_free_bus;
> +
> +	i3cbus->id = ret;
> +	device_initialize(&i3cbus->dev);
> +
> +	return i3cbus;
> +
> +err_free_bus:
> +	kfree(i3cbus);
> +
> +	return ERR_PTR(ret);
> +}
> +
> +void i3c_bus_unregister(struct i3c_bus *bus)
> +{
> +	device_unregister(&bus->dev);
> +}
> +
> +int i3c_bus_register(struct i3c_bus *i3cbus)
> +{
> +	struct i2c_device *i2cdev;
> +
> +	i3c_bus_for_each_i2cdev(i3cbus, i2cdev) {
> +		switch (i2cdev->lvr & I3C_LVR_I2C_INDEX_MASK) {
> +		case I3C_LVR_I2C_INDEX(0):
> +			if (i3cbus->mode < I3C_BUS_MODE_MIXED_FAST)
> +				i3cbus->mode = I3C_BUS_MODE_MIXED_FAST;
> +			break;
> +
> +		case I3C_LVR_I2C_INDEX(1):
> +		case I3C_LVR_I2C_INDEX(2):
> +			if (i3cbus->mode < I3C_BUS_MODE_MIXED_SLOW)
> +				i3cbus->mode = I3C_BUS_MODE_MIXED_SLOW;
> +			break;
> +
> +		default:
> +			return -EINVAL;
> +		}
> +	}
> +
> +	if (!i3cbus->scl_rate.i3c)
> +		i3cbus->scl_rate.i3c = I3C_BUS_TYP_I3C_SCL_RATE;
> +
> +	if (!i3cbus->scl_rate.i2c) {
> +		if (i3cbus->mode == I3C_BUS_MODE_MIXED_SLOW)
> +			i3cbus->scl_rate.i2c = I3C_BUS_I2C_FM_SCL_RATE;
> +		else
> +			i3cbus->scl_rate.i2c = I3C_BUS_I2C_FM_PLUS_SCL_RATE;
> +	}
> +
> +	/*
> +	 * I3C/I2C frequency may have been overridden, check that user-provided
> +	 * values are not exceeding max possible frequency.
> +	 */
> +	if (i3cbus->scl_rate.i3c > I3C_BUS_MAX_I3C_SCL_RATE ||
> +	    i3cbus->scl_rate.i2c > I3C_BUS_I2C_FM_PLUS_SCL_RATE) {
> +		return -EINVAL;
> +	}
> +
> +	dev_set_name(&i3cbus->dev, "i3c-%d", i3cbus->id);
> +
> +	return device_add(&i3cbus->dev);
> +}
> +
> +static int __init i3c_init(void)
> +{
> +	return bus_register(&i3c_bus_type);
> +}
> +subsys_initcall(i3c_init);
> +
> +static void __exit i3c_exit(void)
> +{
> +	idr_destroy(&i3c_bus_idr);
> +	bus_unregister(&i3c_bus_type);
> +}
> +module_exit(i3c_exit);
> +
> +MODULE_AUTHOR("Boris Brezillon<boris.brezillon@free-electrons.com>");
> +MODULE_DESCRIPTION("I3C core");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/i3c/device.c b/drivers/i3c/device.c
> new file mode 100644
> index 000000000000..dcf51150b7cb
> --- /dev/null
> +++ b/drivers/i3c/device.c
> @@ -0,0 +1,344 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> + */
> +
> +#include <linux/slab.h>
> +
> +#include "internals.h"
> +
> +/**
> + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a
> + *				specific device
> + *
> + * @dev: device with which the transfers should be done
> + * @xfers: array of transfers
> + * @nxfers: number of transfers
> + *
> + * Initiate one or several private SDR transfers with @dev.
> + *
> + * This function can sleep and thus cannot be called in atomic context.
> + *
> + * Return: 0 in case of success, a negative error core otherwise.
> + */
> +int i3c_device_do_priv_xfers(struct i3c_device *dev,
> +			     struct i3c_priv_xfer *xfers,
> +			     int nxfers)
> +{
> +	struct i3c_master_controller *master;
> +	int i, ret;
> +
> +	master = i3c_device_get_master(dev);
> +	if (!master)
> +		return -EINVAL;
> +
> +	i3c_bus_normaluse_lock(master->bus);
> +	for (i = 0; i < nxfers; i++)
> +		xfers[i].addr = dev->info.dyn_addr;
> +
> +	ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
> +	i3c_bus_normaluse_unlock(master->bus);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);

 The controller should know the speed mode for each xfer. The SDR0 mode 
is used by default but if any device have read or write speed 
limitations the controller can use SDRx.

This could be also applied to i2c transfers.
> +#endif /* I3C_INTERNAL_H */
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> new file mode 100644
> index 000000000000..1c85abac08d5
> --- /dev/null
> +++ b/drivers/i3c/master.c
> @@ -0,0 +1,1433 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> + */
> +
> +#include <linux/slab.h>
> +
> +#include "internals.h"
> +
> +/**
> + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
> + *				procedure
> + * @master: master used to send frames on the bus
> + *
> + * Send a ENTDAA CCC command to start a DAA procedure.
> + *
> + * Note that this function only sends the ENTDAA CCC command, all the logic
> + * behind dynamic address assignment has to be handled in the I3C master
> + * driver.
> + *
> + * This function must be called with the bus lock held in write mode.
> + *
> + * Return: 0 in case of success, a negative error code otherwise.
> + */
> +int i3c_master_entdaa_locked(struct i3c_master_controller *master)
> +{
> +	struct i3c_ccc_cmd_dest dest = { };
> +	struct i3c_ccc_cmd cmd = { };
> +	int ret;
> +
> +	dest.addr = I3C_BROADCAST_ADDR;
> +	cmd.dests = &dest;
> +	cmd.ndests = 1;
> +	cmd.rnw = false;
> +	cmd.id = I3C_CCC_ENTDAA;
> +
> +	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked);

 can you explain the process?  the command is only execute once, what if 
there is more devices on the bus?

 > +
> +/**
> + * i3c_master_defslvs_locked() - send a DEFSLVS CCC command
> + * @master: master used to send frames on the bus
> + *
> + * Send a DEFSLVS CCC command containing all the devices known to the @master.
> + * This is useful when you have secondary masters on the bus to propagate
> + * device information.
> + *
> + * This should be called after all I3C devices have been discovered (in other
> + * words, after the DAA procedure has finished) and instantiated in
> + * i3c_master_controller_ops->bus_init().
> + * It should also be called if a master ACKed an Hot-Join request and assigned
> + * a dynamic address to the device joining the bus.
> + *
> + * This function must be called with the bus lock held in write mode.
> + *
> + * Return: 0 in case of success, a negative error code otherwise.
> + */
> +int i3c_master_defslvs_locked(struct i3c_master_controller *master)
> +{
> +	struct i3c_ccc_cmd_dest dest = {
> +		.addr = I3C_BROADCAST_ADDR,
> +	};
> +	struct i3c_ccc_cmd cmd = {
> +		.id = I3C_CCC_DEFSLVS,
> +		.dests = &dest,
> +		.ndests = 1,
> +	};
> +	struct i3c_ccc_defslvs *defslvs;
> +	struct i3c_ccc_dev_desc *desc;
> +	struct i3c_device *i3cdev;
> +	struct i2c_device *i2cdev;
> +	struct i3c_bus *bus;
> +	bool send = false;
> +	int ndevs = 0, ret;
> +
> +	if (!master)
> +		return -EINVAL;
> +
> +	bus = i3c_master_get_bus(master);
> +	i3c_bus_for_each_i3cdev(bus, i3cdev) {
> +		ndevs++;
> +		if (I3C_BCR_DEVICE_ROLE(i3cdev->info.bcr) == I3C_BCR_I3C_MASTER)
> +			send = true;
> +	}
> +
> +	/* No other master on the bus, skip DEFSLVS. */
> +	if (!send)
> +		return 0;
> +
> +	i3c_bus_for_each_i2cdev(bus, i2cdev)
> +		ndevs++;
> +
> +	dest.payload.len = sizeof(*defslvs) +
> +			   ((ndevs - 1) * sizeof(struct i3c_ccc_dev_desc));
> +	defslvs = kzalloc(dest.payload.len, GFP_KERNEL);
> +	if (!defslvs)
> +		return -ENOMEM;
> +
> +	dest.payload.data = defslvs;
> +
> +	defslvs->count = ndevs;
> +	defslvs->master.bcr = master->this->info.bcr;
> +	defslvs->master.dcr = master->this->info.dcr;
> +	defslvs->master.dyn_addr = master->this->info.dyn_addr;
> +	defslvs->master.static_addr = I3C_BROADCAST_ADDR;

 Why defslvs->master.static_addr = I3C_BROADCAST_ADDR?

 > +
> +	desc = defslvs->slaves;
> +	i3c_bus_for_each_i2cdev(bus, i2cdev) {
> +		desc->lvr = i2cdev->lvr;
> +		desc->static_addr = i2cdev->info.addr;
> +		desc++;
> +	}
> +
> +	i3c_bus_for_each_i3cdev(bus, i3cdev) {
> +		/* Skip the I3C dev representing this master. */
> +		if (i3cdev == master->this)
> +			continue;
> +
> +		desc->bcr = i3cdev->info.bcr;
> +		desc->dcr = i3cdev->info.dcr;
> +		desc->dyn_addr = i3cdev->info.dyn_addr;
> +		desc->static_addr = i3cdev->info.static_addr;
> +		desc++;
> +	}
> +
> +	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
> +	kfree(defslvs);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(i3c_master_defslvs_locked);
> +
> +
> +static int i3c_master_i2c_adapter_xfer(struct i2c_adapter *adap,
> +				       struct i2c_msg *xfers, int nxfers)
> +{
> +	struct i3c_master_controller *master = i2c_adapter_to_i3c_master(adap);
> +	int i, ret;
> +
> +	for (i = 0; i < nxfers; i++) {
> +		enum i3c_addr_slot_status status;
> +
> +		status = i3c_bus_get_addr_slot_status(master->bus,
> +						      xfers[i].addr);
> +		if (status != I3C_ADDR_SLOT_I2C_DEV)
> +			return -EINVAL;
> +	}
> +
> +	ret = i3c_master_do_i2c_xfers(master, xfers, nxfers);
> +	if (ret)
> +		return ret;
> +
> +	return nxfers;
> +}
> +
> +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap)
> +{
> +	return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR;
> +}

 Is I2C_FUNC_10BIT_ADDR allowed ?

 > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
> new file mode 100644
> index 000000000000..e69de29bb2d1
> diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
> new file mode 100644
> index 000000000000..e69de29bb2d1
> diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h
> new file mode 100644
> index 000000000000..ff3e1a3e2c4c
> --- /dev/null
> +++ b/include/linux/i3c/ccc.h
> @@ -0,0 +1,380 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> + */
> +
> +
> +/**
> + * enum i3c_ccc_test_mode - enum listing all available test modes
> + *
> + * @I3C_CCC_EXIT_TEST_MODE: exit test mode
> + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode
> + */
> +enum i3c_ccc_test_mode {
> +	I3C_CCC_EXIT_TEST_MODE,
> +	I3C_CCC_VENDOR_TEST_MODE,
> +};
> +
> +/**
> + * struct i3c_ccc_enttm - payload passed to ENTTM CCC
> + *
> + * @mode: one of the &enum i3c_ccc_test_mode modes
> + *
> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
> + * specific test mode.
> + */
> +struct i3c_ccc_enttm {
> +	u8 mode;
> +} __packed;
> +
> +/**
> + * struct i3c_ccc_setda - payload passed to ENTTM CCC
> + *
> + * @mode: one of the &enum i3c_ccc_test_mode modes
> + *
> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
> + * specific test mode.
> + */
> +struct i3c_ccc_setda {
> +	u8 addr;
> +} __packed;

 what do you mean with struct? Maybe setdasa? if so, what is the addr?

 > +/**
> + * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers
> + */
> +enum i3c_sdr_max_data_rate {
> +	I3C_SDR_DR_FSCL_MAX,
> +	I3C_SDR_DR_FSCL_8MHZ,
> +	I3C_SDR_DR_FSCL_6MHZ,
> +	I3C_SDR_DR_FSCL_4MHZ,
> +	I3C_SDR_DR_FSCL_2MHZ,
> +};
Can you change the names to:

I3C_SDR0_FSCL_MAX,
I3C_SDR1_FSCL_8MHZ,
I3C_SDR2_FSCL_6MHZ,
I3C_SDR3_FSCL_4MHZ,
I3C_SDR4_FSCL_2MHZ,

thus the data rate isn't repeated.

> +
> +/**
> + * enum i3c_tsco - clock to data turn-around
> + */
> +enum i3c_tsco {
> +	I3C_TSCO_LT_8NS,
> +	I3C_TSCO_LT_9NS,
> +	I3C_TSCO_LT_10NS,
> +	I3C_TSCO_LT_11NS,
> +	I3C_TSCO_LT_12NS,
> +};
what's the meaning of _LT_ ?
> +
> +#endif /* I3C_CCC_H */
> diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h
> new file mode 100644
> index 000000000000..83958d3a02e2
> --- /dev/null
> +++ b/include/linux/i3c/device.h
> @@ -0,0 +1,321 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> + */
> +
> +#ifndef I3C_DEV_H
> +#define I3C_DEV_H
> +
> +#include <linux/device.h>
> +#include <linux/i2c.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +
> +/**
> + * enum i3c_hdr_mode - HDR mode ids
> + * @I3C_HDR_DDR: DDR mode
> + * @I3C_HDR_TSP: TSP mode
> + * @I3C_HDR_TSL: TSL mode
> + */
> +enum i3c_hdr_mode {
> +	I3C_HDR_DDR,
> +	I3C_HDR_TSP,
> +	I3C_HDR_TSL,
> +};
> +
> +/**
> + * struct i3c_hdr_cmd - I3C HDR command
> + * @mode: HDR mode selected for this command
> + * @code: command opcode
> + * @addr: I3C dynamic address
> + * @ndatawords: number of data words (a word is 16bits wide)
> + * @data: input/output buffer
> + */
> +struct i3c_hdr_cmd {
> +	enum i3c_hdr_mode mode;
> +	u8 code;
> +	u8 addr;
> +	int ndatawords;
> +	union {
> +		u16 *in;
> +		const u16 *out;
> +	} data;
> +};
> +
> +/* Private SDR read transfer */
> +#define I3C_PRIV_XFER_READ		BIT(0)
> +/*
> + * Instruct the controller to issue a STOP after a specific transfer instead
> + * of a REPEATED START.
> + */
> +#define I3C_PRIV_XFER_STOP		BIT(1)
> +
> +/**
> + * struct i3c_priv_xfer - I3C SDR private transfer
> + * @addr: I3C dynamic address
> + * @len: transfer length in bytes of the transfer
> + * @flags: combination of I3C_PRIV_XFER_xxx flags
> + * @data: input/output buffer
> + */
> +struct i3c_priv_xfer {
> +	u8 addr;
> +	u16 len;
> +	u32 flags;
> +	struct {
> +		void *in;
> +		const void *out;
> +	} data;
> +};

 Same as above, i3c_sdr_max_data_rate to change the bus scl.

 > +
> +/**
> + * enum i3c_dcr - I3C DCR values
> + * @I3C_DCR_GENERIC_DEVICE: generic I3C device
> + */
> +enum i3c_dcr {
> +	I3C_DCR_GENERIC_DEVICE = 0,
> +};
> +
> +#define I3C_PID_MANUF_ID(pid)		(((pid) & GENMASK_ULL(47, 33)) >> 33)
> +#define I3C_PID_RND_LOWER_32BITS(pid)	(!!((pid) & BIT_ULL(32)))
> +#define I3C_PID_RND_VAL(pid)		((pid) & GENMASK_ULL(31, 0))
> +#define I3C_PID_PART_ID(pid)		(((pid) & GENMASK_ULL(31, 16)) >> 16)
> +#define I3C_PID_INSTANCE_ID(pid)	(((pid) & GENMASK_ULL(15, 12)) >> 12)
> +#define I3C_PID_EXTRA_INFO(pid)		((pid) & GENMASK_ULL(11, 0))
> +
> +#define I3C_BCR_DEVICE_ROLE(bcr)	((bcr) & GENMASK(7, 6))
> +#define I3C_BCR_I3C_SLAVE		(0 << 6)
> +#define I3C_BCR_I3C_MASTER		(1 << 6)
> +#define I3C_BCR_HDR_CAP			BIT(5)
> +#define I3C_BCR_BRIDGE			BIT(4)
> +#define I3C_BCR_OFFLINE_CAP		BIT(3)
> +#define I3C_BCR_IBI_PAYLOAD		BIT(2)
> +#define I3C_BCR_IBI_REQ_CAP		BIT(1)
> +#define I3C_BCR_MAX_DATA_SPEED_LIM	BIT(0)
> +
> +/**
> + * struct i3c_device_info - I3C device information
> + * @pid: Provisional ID
> + * @bcr: Bus Characteristic Register
> + * @dcr: Device Characteristic Register
> + * @static_addr: static/I2C address
> + * @dyn_addr: dynamic address
> + * @hdr_cap: supported HDR modes
> + * @max_read_ds: max read speed information
> + * @max_write_ds: max write speed information
> + * @max_ibi_len: max IBI payload length
> + * @max_read_turnaround: max read turn-around time in micro-seconds
> + * @max_read_len: max private SDR read length in bytes
> + * @max_write_len: max private SDR write length in bytes
> + *
> + * These are all basic information that should be advertised by an I3C device.
> + * Some of them are optional depending on the device type and device
> + * capabilities.
> + * For each I3C slave attached to a master with
> + * i3c_master_add_i3c_dev_locked(), the core will send the relevant CCC command
> + * to retrieve these data.
> + */
> +struct i3c_device_info {
> +	u64 pid;
> +	u8 bcr;
> +	u8 dcr;
> +	u8 static_addr;
> +	u8 dyn_addr;
> +	u8 hdr_cap;
> +	u8 max_read_ds;
> +	u8 max_write_ds;
> +	u8 max_ibi_len;
> +	u32 max_read_turnaround;
> +	u16 max_read_len;
> +	u16 max_write_len;
> +};
> +

 is this information filled with data provided from CCC commands?

 > +
> +#endif /* I3C_DEV_H */
> diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
> new file mode 100644
> index 000000000000..7ec9a4821bac
> --- /dev/null
> +++ b/include/linux/i3c/master.h
> @@ -0,0 +1,564 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> + */
> +
> +#ifndef I3C_MASTER_H
> +#define I3C_MASTER_H
> +
> +#include <linux/i2c.h>
> +#include <linux/i3c/ccc.h>
> +#include <linux/i3c/device.h>
> +#include <linux/spinlock.h>
> +
> +#define I3C_HOT_JOIN_ADDR		0x2
> +#define I3C_BROADCAST_ADDR		0x7e
> +#define I3C_MAX_ADDR			GENMASK(6, 0)
> +
> +struct i3c_master_controller;
> +struct i3c_bus;
> +
> +/**
> + * struct i3c_i2c_dev - I3C/I2C common information
> + * @node: node element used to insert the device into the I2C or I3C device
> + *	  list
> + * @bus: I3C bus this device is connected to
> + * @master: I3C master that instantiated this device. Will be used to send
> + *	    I2C/I3C frames on the bus
> + * @master_priv: master private data assigned to the device. Can be used to
> + *		 add master specific information
> + *
> + * This structure is describing common I3C/I2C dev information.
> + */
> +struct i3c_i2c_dev {
> +	struct list_head node;
> +	struct i3c_bus *bus;
> +	struct i3c_master_controller *master;
> +	void *master_priv;
> +};
> +
> +#define I3C_LVR_I2C_INDEX_MASK		GENMASK(7, 5)
> +#define I3C_LVR_I2C_INDEX(x)		((x) << 5)
> +#define I3C_LVR_I2C_FM_MODE		BIT(4)
> +
> +#define I2C_MAX_ADDR			GENMASK(9, 0)

 why 10-bit address?

 > +
> +/**
> + * struct i2c_device - I2C device object
> + * @common: inherit common I3C/I2C description
> + * @info: I2C board info used to instantiate the I2C device. If you are
> + *	  using DT to describe your hardware, this will be filled for you
> + * @client: I2C client object created by the I2C framework. This will only
> + *	    be valid after i3c_master_register() returns
> + * @lvr: Legacy Virtual Register value as described in the I3C specification
> + *
> + * I2C device object. Note that the real I2C device is represented by
> + * i2c_device->client, but we need extra information to handle the device when
> + * it's connected to an I3C bus, hence the &struct i2c_device wrapper.
> + *
> + * The I2C framework is not impacted by this new representation.
> + */
> +struct i2c_device {
> +	struct i3c_i2c_dev common;
> +	struct i2c_board_info info;
> +	struct i2c_client *client;
> +	u8 lvr;
> +};
> +

 It is usefull to know the speed limitations of the device.

 > +
> +/**
> + * enum i3c_addr_slot_status - I3C address slot status
> + * @I3C_ADDR_SLOT_FREE: address is free
> + * @I3C_ADDR_SLOT_RSVD: address is reserved
> + * @I3C_ADDR_SLOT_I2C_DEV: address is assigned to an I2C device
> + * @I3C_ADDR_SLOT_I3C_DEV: address is assigned to an I3C device
> + * @I3C_ADDR_SLOT_STATUS_MASK: address slot mask
> + *
> + * On an I3C bus, addresses are assigned dynamically, and we need to know which
> + * addresses are free to use and which ones are already assigned.
> + *
> + * Addresses marked as reserved are those reserved by the I3C protocol
> + * (broadcast address, ...).
> + */
> +enum i3c_addr_slot_status {
> +	I3C_ADDR_SLOT_FREE,
> +	I3C_ADDR_SLOT_RSVD,
> +	I3C_ADDR_SLOT_I2C_DEV,
> +	I3C_ADDR_SLOT_I3C_DEV,
> +	I3C_ADDR_SLOT_STATUS_MASK = 3,
> +};
> +
> +/**
> + * struct i3c_bus - I3C bus object
> + * @dev: device to be registered to the device-model
> + * @cur_master: I3C master currently driving the bus. Since I3C is multi-master
> + *		this can change over the time. Will be used to let a master
> + *		know whether it needs to request bus ownership before sending
> + *		a frame or not
> + * @id: bus ID. Assigned by the framework when register the bus
> + * @addrslots: a bitmap with 2-bits per-slot to encode the address status and
> + *	       ease the DAA (Dynamic Address Assignment) procedure (see
> + *	       &enum i3c_addr_slot_status)
> + * @mode: bus mode (see &enum i3c_bus_mode)
> + * @scl_rate: SCL signal rate for I3C and I2C mode
> + * @devs: 2 lists containing all I3C/I2C devices connected to the bus
> + * @lock: read/write lock on the bus. This is needed to protect against
> + *	  operations that have an impact on the whole bus and the devices
> + *	  connected to it. For example, when asking slaves to drop their
> + *	  dynamic address (RSTDAA CCC), we need to make sure no one is trying
> + *	  to send I3C frames to these devices.
> + *	  Note that this lock does not protect against concurrency between
> + *	  devices: several drivers can send different I3C/I2C frames through
> + *	  the same master in parallel. This is the responsibility of the
> + *	  master to guarantee that frames are actually sent sequentially and
> + *	  not interlaced
> + *
> + * The I3C bus is represented with its own object and not implicitly described
> + * by the I3C master to cope with the multi-master functionality, where one bus
> + * can be shared amongst several masters, each of them requesting bus ownership
> + * when they need to.
> + */
> +struct i3c_bus {
> +	struct device dev;
> +	struct i3c_device *cur_master;
> +	int id;
> +	unsigned long addrslots[((I2C_MAX_ADDR + 1) * 2) / BITS_PER_LONG];
> +	enum i3c_bus_mode mode;
> +	struct {
> +		unsigned long i3c;
> +		unsigned long i2c;
> +	} scl_rate;
> +	struct {
> +		struct list_head i3c;
> +		struct list_head i2c;
> +	} devs;
> +	struct rw_semaphore lock;
> +};
Can you explain the addrslots[] ?
> +
> +static inline struct i3c_device *dev_to_i3cdev(struct device *dev)
> +{
> +	return container_of(dev, struct i3c_device, dev);
> +}
> +
> +struct i3c_master_controller;
> +
> +/**
> + * struct i3c_master_controller_ops - I3C master methods
> + * @bus_init: hook responsible for the I3C bus initialization. This
> + *	      initialization should follow the steps described in the I3C
> + *	      specification. This hook is called with the bus lock held in
> + *	      write mode, which means all _locked() helpers can safely be
> + *	      called from there
> + * @bus_cleanup: cleanup everything done in
> + *		 &i3c_master_controller_ops->bus_init(). This function is
> + *		 optional and should only be implemented if
> + *		 &i3c_master_controller_ops->bus_init() attached private data
> + *		 to I3C/I2C devices. This hook is called with the bus lock
> + *		 held in write mode, which means all _locked() helpers can
> + *		 safely be called from there
> + * @supports_ccc_cmd: should return true if the CCC command is supported, false
> + *		      otherwise
> + * @send_ccc_cmd: send a CCC command
> + * @send_hdr_cmds: send one or several HDR commands. If there is more than one
> + *		   command, they should ideally be sent in the same HDR
> + *		   transaction
> + * @priv_xfers: do one or several private I3C SDR transfers
> + * @i2c_xfers: do one or several I2C transfers
> + * @request_ibi: attach an IBI handler to an I3C device. This implies defining
> + *		 an IBI handler and the constraints of the IBI (maximum payload
> + *		 length and number of pre-allocated slots).
> + *		 Some controllers support less IBI-capable devices than regular
> + *		 devices, so this method might return -%EBUSY if there's no
> + *		 more space for an extra IBI registration
> + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI
> + *	      should have been disabled with ->disable_irq() prior to that
> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called
> + *		prior to ->enable_ibi(). The controller should first enable
> + *		the IBI on the controller end (for example, unmask the hardware
> + *		IRQ) and then send the ENEC CCC command (with the IBI flag set)
> + *		to the I3C device
> + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI
> + *		 flag set and then deactivate the hardware IRQ on the
> + *		 controller end
> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been
> + *		      processed by its handler. The IBI slot should be put back
> + *		      in the IBI slot pool so that the controller can re-use it
> + *		      for a future IBI
> + *
> + * One of the most important hooks in these ops is
> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of
> + * things that should be done in &i3c_master_controller_ops->bus_init():
> + *
> + * 1) call i3c_master_set_info() with all information describing the master
> + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC
> + *    with i3c_master_rstdaa_locked()
> + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked()
> + * 4) start a DDA procedure by sending the ENTDAA CCC with
> + *    i3c_master_entdaa_locked(), or using the internal DAA logic provided by
> + *    your controller
You mean SETDASA CCC command?
> + * 5) assign a dynamic address to each I3C device discovered during DAA and
> + *    for each of them, call i3c_master_add_i3c_dev_locked()
> + * 6) propagate device table to secondary masters by calling
> + *    i3c_master_defslvs_locked()
> + *
> + * Note that these steps do not include all controller specific initialization.
> + */
> +struct i3c_master_controller_ops {
> +	int (*bus_init)(struct i3c_master_controller *master);
> +	void (*bus_cleanup)(struct i3c_master_controller *master);
> +	bool (*supports_ccc_cmd)(struct i3c_master_controller *master,
> +				 const struct i3c_ccc_cmd *cmd);
> +	int (*send_ccc_cmd)(struct i3c_master_controller *master,
> +			    struct i3c_ccc_cmd *cmd);
> +	int (*send_hdr_cmds)(struct i3c_master_controller *master,
> +			     const struct i3c_hdr_cmd *cmds,
> +			     int ncmds);
> +	int (*priv_xfers)(struct i3c_master_controller *master,
> +			  const struct i3c_priv_xfer *xfers,
> +			  int nxfers);
> +	int (*i2c_xfers)(struct i3c_master_controller *master,
> +			 const struct i2c_msg *xfers, int nxfers);
> +	int (*request_ibi)(struct i3c_master_controller *master,
> +			   struct i3c_device *dev,
> +			   const struct i3c_ibi_setup *req);
> +	void (*free_ibi)(struct i3c_master_controller *master,
> +			 struct i3c_device *dev);
> +	int (*enable_ibi)(struct i3c_master_controller *master,
> +			  struct i3c_device *dev);
> +	int (*disable_ibi)(struct i3c_master_controller *master,
> +			   struct i3c_device *dev);
> +	void (*recycle_ibi_slot)(struct i3c_master_controller *master,
> +				 struct i3c_device *dev,
> +				 struct i3c_ibi_slot *slot);
> +};
> +
>

Best regards,
Vitor Soares

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-23 16:56   ` Vitor Soares
@ 2018-02-23 20:30     ` Boris Brezillon
  2018-02-26 18:58       ` Vitor Soares
  2018-02-23 22:45     ` Boris Brezillon
  1 sibling, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2018-02-23 20:30 UTC (permalink / raw)
  To: Vitor Soares
  Cc: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

Hi Vitor,

On Fri, 23 Feb 2018 16:56:14 +0000
Vitor Soares <Vitor.Soares@synopsys.com> wrote:

> Hi Boris,
> 
> Às 3:16 PM de 12/14/2017, Boris Brezillon escreveu:
> > +
> > +enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus,
> > +						       u16 addr)
> > +{
> > +	int status, bitpos = addr * 2;
> > +
> > +	if (addr > I2C_MAX_ADDR)
> > +		return I3C_ADDR_SLOT_RSVD;
> > +
> > +	status = bus->addrslots[bitpos / BITS_PER_LONG];
> > +	status >>= bitpos % BITS_PER_LONG;
> > +
> > +	return status & I3C_ADDR_SLOT_STATUS_MASK;
> > +}  
> 
> I don't understand the size of addr. The I3C only allow 7-bit addresses.
> 
> Is the addrslots used to store the addresses and its status?

No, slots are used for both I2C and I3C addresses, and an I2C address
can be 10-bits wide, hence the u16 type.


[...]

> > +/**
> > + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a
> > + *				specific device
> > + *
> > + * @dev: device with which the transfers should be done
> > + * @xfers: array of transfers
> > + * @nxfers: number of transfers
> > + *
> > + * Initiate one or several private SDR transfers with @dev.
> > + *
> > + * This function can sleep and thus cannot be called in atomic context.
> > + *
> > + * Return: 0 in case of success, a negative error core otherwise.
> > + */
> > +int i3c_device_do_priv_xfers(struct i3c_device *dev,
> > +			     struct i3c_priv_xfer *xfers,
> > +			     int nxfers)
> > +{
> > +	struct i3c_master_controller *master;
> > +	int i, ret;
> > +
> > +	master = i3c_device_get_master(dev);
> > +	if (!master)
> > +		return -EINVAL;
> > +
> > +	i3c_bus_normaluse_lock(master->bus);
> > +	for (i = 0; i < nxfers; i++)
> > +		xfers[i].addr = dev->info.dyn_addr;
> > +
> > +	ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
> > +	i3c_bus_normaluse_unlock(master->bus);
> > +
> > +	return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);  
> 
>  The controller should know the speed mode for each xfer. The SDR0 mode 
> is used by default but if any device have read or write speed 
> limitations the controller can use SDRx.

I might be wrong, but that's not my understanding of the spec. A device
can express a speed limitation for SDR priv transfers, but this
limitation applies to all SDR transfers.

The speed R/W speed limitation is encoded in the device object, so, if
the controller has to configure that on a per-transfer basis, one
solution would be to pass the device to the ->priv_xfers().

> 
> This could be also applied to i2c transfers.

Not really. The max SCL frequency is something that applies to the
whole bus, because all I2C devices have to decode the address when
messages are sent on the bus to determine if they should ignore or
process the message.

> > +#endif /* I3C_INTERNAL_H */
> > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> > new file mode 100644
> > index 000000000000..1c85abac08d5
> > --- /dev/null
> > +++ b/drivers/i3c/master.c
> > @@ -0,0 +1,1433 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> > + */
> > +
> > +#include <linux/slab.h>
> > +
> > +#include "internals.h"
> > +
> > +/**
> > + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
> > + *				procedure
> > + * @master: master used to send frames on the bus
> > + *
> > + * Send a ENTDAA CCC command to start a DAA procedure.
> > + *
> > + * Note that this function only sends the ENTDAA CCC command, all the logic
> > + * behind dynamic address assignment has to be handled in the I3C master
> > + * driver.
> > + *
> > + * This function must be called with the bus lock held in write mode.
> > + *
> > + * Return: 0 in case of success, a negative error code otherwise.
> > + */
> > +int i3c_master_entdaa_locked(struct i3c_master_controller *master)
> > +{
> > +	struct i3c_ccc_cmd_dest dest = { };
> > +	struct i3c_ccc_cmd cmd = { };
> > +	int ret;
> > +
> > +	dest.addr = I3C_BROADCAST_ADDR;
> > +	cmd.dests = &dest;
> > +	cmd.ndests = 1;
> > +	cmd.rnw = false;
> > +	cmd.id = I3C_CCC_ENTDAA;
> > +
> > +	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked);  
> 
>  can you explain the process?

Not sure what you mean. The ENTDAA is just a CCC command that is used
to trigger a DAA procedure. What the master controller does when it
sends such a command is likely to be controller dependent, and it might
even be possible that you don't need to call this function in your
controller driver to trigger a DAA. If you want more details about the
bus initialization steps and how the ENTDAA CCC command fits into it I
recommend reading section "5.1.4 Bus Initialization and Dynamic Address
Assignment Mode"

> the command is only execute once, what if 
> there is more devices on the bus?

Again, I'm not sure what you mean. The ENTDAA command is sent every
time a controller wants to discover new devices on the bus, that can be
when initializing the bus, after a Hot Join event or simply triggered
by the user (the last case is not supported yet though).

Now, if you're interested in what happens after an ENTDAA CCC is sent,
the controller will keep sending RepeatedStart until there's no more
devices acking the request. You can have a look at "B.3 Error Types in
Dynamic Address Arbitration" for more details.

> 
>  > +
> > +/**
> > + * i3c_master_defslvs_locked() - send a DEFSLVS CCC command
> > + * @master: master used to send frames on the bus
> > + *
> > + * Send a DEFSLVS CCC command containing all the devices known to the @master.
> > + * This is useful when you have secondary masters on the bus to propagate
> > + * device information.
> > + *
> > + * This should be called after all I3C devices have been discovered (in other
> > + * words, after the DAA procedure has finished) and instantiated in
> > + * i3c_master_controller_ops->bus_init().
> > + * It should also be called if a master ACKed an Hot-Join request and assigned
> > + * a dynamic address to the device joining the bus.
> > + *
> > + * This function must be called with the bus lock held in write mode.
> > + *
> > + * Return: 0 in case of success, a negative error code otherwise.
> > + */
> > +int i3c_master_defslvs_locked(struct i3c_master_controller *master)
> > +{
> > +	struct i3c_ccc_cmd_dest dest = {
> > +		.addr = I3C_BROADCAST_ADDR,
> > +	};
> > +	struct i3c_ccc_cmd cmd = {
> > +		.id = I3C_CCC_DEFSLVS,
> > +		.dests = &dest,
> > +		.ndests = 1,
> > +	};
> > +	struct i3c_ccc_defslvs *defslvs;
> > +	struct i3c_ccc_dev_desc *desc;
> > +	struct i3c_device *i3cdev;
> > +	struct i2c_device *i2cdev;
> > +	struct i3c_bus *bus;
> > +	bool send = false;
> > +	int ndevs = 0, ret;
> > +
> > +	if (!master)
> > +		return -EINVAL;
> > +
> > +	bus = i3c_master_get_bus(master);
> > +	i3c_bus_for_each_i3cdev(bus, i3cdev) {
> > +		ndevs++;
> > +		if (I3C_BCR_DEVICE_ROLE(i3cdev->info.bcr) == I3C_BCR_I3C_MASTER)
> > +			send = true;
> > +	}
> > +
> > +	/* No other master on the bus, skip DEFSLVS. */
> > +	if (!send)
> > +		return 0;
> > +
> > +	i3c_bus_for_each_i2cdev(bus, i2cdev)
> > +		ndevs++;
> > +
> > +	dest.payload.len = sizeof(*defslvs) +
> > +			   ((ndevs - 1) * sizeof(struct i3c_ccc_dev_desc));
> > +	defslvs = kzalloc(dest.payload.len, GFP_KERNEL);
> > +	if (!defslvs)
> > +		return -ENOMEM;
> > +
> > +	dest.payload.data = defslvs;
> > +
> > +	defslvs->count = ndevs;
> > +	defslvs->master.bcr = master->this->info.bcr;
> > +	defslvs->master.dcr = master->this->info.dcr;
> > +	defslvs->master.dyn_addr = master->this->info.dyn_addr;
> > +	defslvs->master.static_addr = I3C_BROADCAST_ADDR;  
> 
>  Why defslvs->master.static_addr = I3C_BROADCAST_ADDR?

I just follow what's document in "5.1.9.3.7 Define List of Slaves
(DEFSLVS)"

> 
>  > +
> > +	desc = defslvs->slaves;
> > +	i3c_bus_for_each_i2cdev(bus, i2cdev) {
> > +		desc->lvr = i2cdev->lvr;
> > +		desc->static_addr = i2cdev->info.addr;
> > +		desc++;
> > +	}
> > +
> > +	i3c_bus_for_each_i3cdev(bus, i3cdev) {
> > +		/* Skip the I3C dev representing this master. */
> > +		if (i3cdev == master->this)
> > +			continue;
> > +
> > +		desc->bcr = i3cdev->info.bcr;
> > +		desc->dcr = i3cdev->info.dcr;
> > +		desc->dyn_addr = i3cdev->info.dyn_addr;
> > +		desc->static_addr = i3cdev->info.static_addr;
> > +		desc++;
> > +	}
> > +
> > +	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
> > +	kfree(defslvs);
> > +
> > +	return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_master_defslvs_locked);
> > +
> > +
> > +static int i3c_master_i2c_adapter_xfer(struct i2c_adapter *adap,
> > +				       struct i2c_msg *xfers, int nxfers)
> > +{
> > +	struct i3c_master_controller *master = i2c_adapter_to_i3c_master(adap);
> > +	int i, ret;
> > +
> > +	for (i = 0; i < nxfers; i++) {
> > +		enum i3c_addr_slot_status status;
> > +
> > +		status = i3c_bus_get_addr_slot_status(master->bus,
> > +						      xfers[i].addr);
> > +		if (status != I3C_ADDR_SLOT_I2C_DEV)
> > +			return -EINVAL;
> > +	}
> > +
> > +	ret = i3c_master_do_i2c_xfers(master, xfers, nxfers);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return nxfers;
> > +}
> > +
> > +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap)
> > +{
> > +	return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR;
> > +}  
> 
>  Is I2C_FUNC_10BIT_ADDR allowed ?

According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes (at
least that my understanding). And the Cadence controller supports it.

> 
>  > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
> > new file mode 100644
> > index 000000000000..e69de29bb2d1
> > diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
> > new file mode 100644
> > index 000000000000..e69de29bb2d1
> > diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h
> > new file mode 100644
> > index 000000000000..ff3e1a3e2c4c
> > --- /dev/null
> > +++ b/include/linux/i3c/ccc.h
> > @@ -0,0 +1,380 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> > + */
> > +
> > +
> > +/**
> > + * enum i3c_ccc_test_mode - enum listing all available test modes
> > + *
> > + * @I3C_CCC_EXIT_TEST_MODE: exit test mode
> > + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode
> > + */
> > +enum i3c_ccc_test_mode {
> > +	I3C_CCC_EXIT_TEST_MODE,
> > +	I3C_CCC_VENDOR_TEST_MODE,
> > +};
> > +
> > +/**
> > + * struct i3c_ccc_enttm - payload passed to ENTTM CCC
> > + *
> > + * @mode: one of the &enum i3c_ccc_test_mode modes
> > + *
> > + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
> > + * specific test mode.
> > + */
> > +struct i3c_ccc_enttm {
> > +	u8 mode;
> > +} __packed;
> > +
> > +/**
> > + * struct i3c_ccc_setda - payload passed to ENTTM CCC
> > + *
> > + * @mode: one of the &enum i3c_ccc_test_mode modes
> > + *
> > + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
> > + * specific test mode.
> > + */
> > +struct i3c_ccc_setda {
> > +	u8 addr;
> > +} __packed;  
> 
>  what do you mean with struct? Maybe setdasa? if so, what is the addr?
> 
>  > +/**
> > + * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers
> > + */
> > +enum i3c_sdr_max_data_rate {
> > +	I3C_SDR_DR_FSCL_MAX,
> > +	I3C_SDR_DR_FSCL_8MHZ,
> > +	I3C_SDR_DR_FSCL_6MHZ,
> > +	I3C_SDR_DR_FSCL_4MHZ,
> > +	I3C_SDR_DR_FSCL_2MHZ,
> > +};  
> Can you change the names to:
> 
> I3C_SDR0_FSCL_MAX,
> I3C_SDR1_FSCL_8MHZ,
> I3C_SDR2_FSCL_6MHZ,
> I3C_SDR3_FSCL_4MHZ,
> I3C_SDR4_FSCL_2MHZ,
> 
> thus the data rate isn't repeated.

What's the problem with the name I use? Moreover, I see no mention to
the SDR0,1,2,3,4 modes in the public spec.

> 
> > +
> > +/**
> > + * enum i3c_tsco - clock to data turn-around
> > + */
> > +enum i3c_tsco {
> > +	I3C_TSCO_LT_8NS,
> > +	I3C_TSCO_LT_9NS,
> > +	I3C_TSCO_LT_10NS,
> > +	I3C_TSCO_LT_11NS,
> > +	I3C_TSCO_LT_12NS,
> > +};  
> what's the meaning of _LT_ ?

This I don't remember. I'll drop it in the next version.

> > +
> > +#endif /* I3C_CCC_H */
> > diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h
> > new file mode 100644
> > index 000000000000..83958d3a02e2
> > --- /dev/null
> > +++ b/include/linux/i3c/device.h
> > @@ -0,0 +1,321 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> > + */
> > +
> > +#ifndef I3C_DEV_H
> > +#define I3C_DEV_H
> > +
> > +#include <linux/device.h>
> > +#include <linux/i2c.h>
> > +#include <linux/mod_devicetable.h>
> > +#include <linux/module.h>
> > +
> > +/**
> > + * enum i3c_hdr_mode - HDR mode ids
> > + * @I3C_HDR_DDR: DDR mode
> > + * @I3C_HDR_TSP: TSP mode
> > + * @I3C_HDR_TSL: TSL mode
> > + */
> > +enum i3c_hdr_mode {
> > +	I3C_HDR_DDR,
> > +	I3C_HDR_TSP,
> > +	I3C_HDR_TSL,
> > +};
> > +
> > +/**
> > + * struct i3c_hdr_cmd - I3C HDR command
> > + * @mode: HDR mode selected for this command
> > + * @code: command opcode
> > + * @addr: I3C dynamic address
> > + * @ndatawords: number of data words (a word is 16bits wide)
> > + * @data: input/output buffer
> > + */
> > +struct i3c_hdr_cmd {
> > +	enum i3c_hdr_mode mode;
> > +	u8 code;
> > +	u8 addr;
> > +	int ndatawords;
> > +	union {
> > +		u16 *in;
> > +		const u16 *out;
> > +	} data;
> > +};
> > +
> > +/* Private SDR read transfer */
> > +#define I3C_PRIV_XFER_READ		BIT(0)
> > +/*
> > + * Instruct the controller to issue a STOP after a specific transfer instead
> > + * of a REPEATED START.
> > + */
> > +#define I3C_PRIV_XFER_STOP		BIT(1)
> > +
> > +/**
> > + * struct i3c_priv_xfer - I3C SDR private transfer
> > + * @addr: I3C dynamic address
> > + * @len: transfer length in bytes of the transfer
> > + * @flags: combination of I3C_PRIV_XFER_xxx flags
> > + * @data: input/output buffer
> > + */
> > +struct i3c_priv_xfer {
> > +	u8 addr;
> > +	u16 len;
> > +	u32 flags;
> > +	struct {
> > +		void *in;
> > +		const void *out;
> > +	} data;
> > +};  
> 
>  Same as above, i3c_sdr_max_data_rate to change the bus scl.

If I'm understanding the spec correctly, that's not something you want
to change on a per-transfer basis. The constraint is on the device
itself and should IMO not be part of the i3c_priv_xfer struct.

> 
>  > +
> > +/**
> > + * enum i3c_dcr - I3C DCR values
> > + * @I3C_DCR_GENERIC_DEVICE: generic I3C device
> > + */
> > +enum i3c_dcr {
> > +	I3C_DCR_GENERIC_DEVICE = 0,
> > +};
> > +
> > +#define I3C_PID_MANUF_ID(pid)		(((pid) & GENMASK_ULL(47, 33)) >> 33)
> > +#define I3C_PID_RND_LOWER_32BITS(pid)	(!!((pid) & BIT_ULL(32)))
> > +#define I3C_PID_RND_VAL(pid)		((pid) & GENMASK_ULL(31, 0))
> > +#define I3C_PID_PART_ID(pid)		(((pid) & GENMASK_ULL(31, 16)) >> 16)
> > +#define I3C_PID_INSTANCE_ID(pid)	(((pid) & GENMASK_ULL(15, 12)) >> 12)
> > +#define I3C_PID_EXTRA_INFO(pid)		((pid) & GENMASK_ULL(11, 0))
> > +
> > +#define I3C_BCR_DEVICE_ROLE(bcr)	((bcr) & GENMASK(7, 6))
> > +#define I3C_BCR_I3C_SLAVE		(0 << 6)
> > +#define I3C_BCR_I3C_MASTER		(1 << 6)
> > +#define I3C_BCR_HDR_CAP			BIT(5)
> > +#define I3C_BCR_BRIDGE			BIT(4)
> > +#define I3C_BCR_OFFLINE_CAP		BIT(3)
> > +#define I3C_BCR_IBI_PAYLOAD		BIT(2)
> > +#define I3C_BCR_IBI_REQ_CAP		BIT(1)
> > +#define I3C_BCR_MAX_DATA_SPEED_LIM	BIT(0)
> > +
> > +/**
> > + * struct i3c_device_info - I3C device information
> > + * @pid: Provisional ID
> > + * @bcr: Bus Characteristic Register
> > + * @dcr: Device Characteristic Register
> > + * @static_addr: static/I2C address
> > + * @dyn_addr: dynamic address
> > + * @hdr_cap: supported HDR modes
> > + * @max_read_ds: max read speed information
> > + * @max_write_ds: max write speed information
> > + * @max_ibi_len: max IBI payload length
> > + * @max_read_turnaround: max read turn-around time in micro-seconds
> > + * @max_read_len: max private SDR read length in bytes
> > + * @max_write_len: max private SDR write length in bytes
> > + *
> > + * These are all basic information that should be advertised by an I3C device.
> > + * Some of them are optional depending on the device type and device
> > + * capabilities.
> > + * For each I3C slave attached to a master with
> > + * i3c_master_add_i3c_dev_locked(), the core will send the relevant CCC command
> > + * to retrieve these data.
> > + */
> > +struct i3c_device_info {
> > +	u64 pid;
> > +	u8 bcr;
> > +	u8 dcr;
> > +	u8 static_addr;
> > +	u8 dyn_addr;
> > +	u8 hdr_cap;
> > +	u8 max_read_ds;
> > +	u8 max_write_ds;
> > +	u8 max_ibi_len;
> > +	u32 max_read_turnaround;
> > +	u16 max_read_len;
> > +	u16 max_write_len;
> > +};
> > +  
> 
>  is this information filled with data provided from CCC commands?

Yes, they are.

> 
>  > +
> > +#endif /* I3C_DEV_H */
> > diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
> > new file mode 100644
> > index 000000000000..7ec9a4821bac
> > --- /dev/null
> > +++ b/include/linux/i3c/master.h
> > @@ -0,0 +1,564 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> > + */
> > +
> > +#ifndef I3C_MASTER_H
> > +#define I3C_MASTER_H
> > +
> > +#include <linux/i2c.h>
> > +#include <linux/i3c/ccc.h>
> > +#include <linux/i3c/device.h>
> > +#include <linux/spinlock.h>
> > +
> > +#define I3C_HOT_JOIN_ADDR		0x2
> > +#define I3C_BROADCAST_ADDR		0x7e
> > +#define I3C_MAX_ADDR			GENMASK(6, 0)
> > +
> > +struct i3c_master_controller;
> > +struct i3c_bus;
> > +
> > +/**
> > + * struct i3c_i2c_dev - I3C/I2C common information
> > + * @node: node element used to insert the device into the I2C or I3C device
> > + *	  list
> > + * @bus: I3C bus this device is connected to
> > + * @master: I3C master that instantiated this device. Will be used to send
> > + *	    I2C/I3C frames on the bus
> > + * @master_priv: master private data assigned to the device. Can be used to
> > + *		 add master specific information
> > + *
> > + * This structure is describing common I3C/I2C dev information.
> > + */
> > +struct i3c_i2c_dev {
> > +	struct list_head node;
> > +	struct i3c_bus *bus;
> > +	struct i3c_master_controller *master;
> > +	void *master_priv;
> > +};
> > +
> > +#define I3C_LVR_I2C_INDEX_MASK		GENMASK(7, 5)
> > +#define I3C_LVR_I2C_INDEX(x)		((x) << 5)
> > +#define I3C_LVR_I2C_FM_MODE		BIT(4)
> > +
> > +#define I2C_MAX_ADDR			GENMASK(9, 0)  
> 
>  why 10-bit address?
> 

Because some I2C devices have 10-bit addresses.

>  > +
> > +/**
> > + * struct i2c_device - I2C device object
> > + * @common: inherit common I3C/I2C description
> > + * @info: I2C board info used to instantiate the I2C device. If you are
> > + *	  using DT to describe your hardware, this will be filled for you
> > + * @client: I2C client object created by the I2C framework. This will only
> > + *	    be valid after i3c_master_register() returns
> > + * @lvr: Legacy Virtual Register value as described in the I3C specification
> > + *
> > + * I2C device object. Note that the real I2C device is represented by
> > + * i2c_device->client, but we need extra information to handle the device when
> > + * it's connected to an I3C bus, hence the &struct i2c_device wrapper.
> > + *
> > + * The I2C framework is not impacted by this new representation.
> > + */
> > +struct i2c_device {
> > +	struct i3c_i2c_dev common;
> > +	struct i2c_board_info info;
> > +	struct i2c_client *client;
> > +	u8 lvr;
> > +};
> > +  
> 
>  It is usefull to know the speed limitations of the device.

See my previous explanation about I2C and the max frequency. BTW, the
FM vs FM+ information is already encoded in the ->lvr field.

> 
>  > +
> > +/**
> > + * enum i3c_addr_slot_status - I3C address slot status
> > + * @I3C_ADDR_SLOT_FREE: address is free
> > + * @I3C_ADDR_SLOT_RSVD: address is reserved
> > + * @I3C_ADDR_SLOT_I2C_DEV: address is assigned to an I2C device
> > + * @I3C_ADDR_SLOT_I3C_DEV: address is assigned to an I3C device
> > + * @I3C_ADDR_SLOT_STATUS_MASK: address slot mask
> > + *
> > + * On an I3C bus, addresses are assigned dynamically, and we need to know which
> > + * addresses are free to use and which ones are already assigned.
> > + *
> > + * Addresses marked as reserved are those reserved by the I3C protocol
> > + * (broadcast address, ...).
> > + */
> > +enum i3c_addr_slot_status {
> > +	I3C_ADDR_SLOT_FREE,
> > +	I3C_ADDR_SLOT_RSVD,
> > +	I3C_ADDR_SLOT_I2C_DEV,
> > +	I3C_ADDR_SLOT_I3C_DEV,
> > +	I3C_ADDR_SLOT_STATUS_MASK = 3,
> > +};
> > +
> > +/**
> > + * struct i3c_bus - I3C bus object
> > + * @dev: device to be registered to the device-model
> > + * @cur_master: I3C master currently driving the bus. Since I3C is multi-master
> > + *		this can change over the time. Will be used to let a master
> > + *		know whether it needs to request bus ownership before sending
> > + *		a frame or not
> > + * @id: bus ID. Assigned by the framework when register the bus
> > + * @addrslots: a bitmap with 2-bits per-slot to encode the address status and
> > + *	       ease the DAA (Dynamic Address Assignment) procedure (see
> > + *	       &enum i3c_addr_slot_status)
> > + * @mode: bus mode (see &enum i3c_bus_mode)
> > + * @scl_rate: SCL signal rate for I3C and I2C mode
> > + * @devs: 2 lists containing all I3C/I2C devices connected to the bus
> > + * @lock: read/write lock on the bus. This is needed to protect against
> > + *	  operations that have an impact on the whole bus and the devices
> > + *	  connected to it. For example, when asking slaves to drop their
> > + *	  dynamic address (RSTDAA CCC), we need to make sure no one is trying
> > + *	  to send I3C frames to these devices.
> > + *	  Note that this lock does not protect against concurrency between
> > + *	  devices: several drivers can send different I3C/I2C frames through
> > + *	  the same master in parallel. This is the responsibility of the
> > + *	  master to guarantee that frames are actually sent sequentially and
> > + *	  not interlaced
> > + *
> > + * The I3C bus is represented with its own object and not implicitly described
> > + * by the I3C master to cope with the multi-master functionality, where one bus
> > + * can be shared amongst several masters, each of them requesting bus ownership
> > + * when they need to.
> > + */
> > +struct i3c_bus {
> > +	struct device dev;
> > +	struct i3c_device *cur_master;
> > +	int id;
> > +	unsigned long addrslots[((I2C_MAX_ADDR + 1) * 2) / BITS_PER_LONG];
> > +	enum i3c_bus_mode mode;
> > +	struct {
> > +		unsigned long i3c;
> > +		unsigned long i2c;
> > +	} scl_rate;
> > +	struct {
> > +		struct list_head i3c;
> > +		struct list_head i2c;
> > +	} devs;
> > +	struct rw_semaphore lock;
> > +};  
> Can you explain the addrslots[] ?

It's a bitmap encoding the status of I3C/I2C addresses: are they
assigned, reserved of free, and if they are assigned is it an I3C or
I2C device. That's particularly useful to master controller drivers
to know which addresses they can assign during DAA.

I'll try to clarify it in the kernel-doc header.  

> > +
> > +static inline struct i3c_device *dev_to_i3cdev(struct device *dev)
> > +{
> > +	return container_of(dev, struct i3c_device, dev);
> > +}
> > +
> > +struct i3c_master_controller;
> > +
> > +/**
> > + * struct i3c_master_controller_ops - I3C master methods
> > + * @bus_init: hook responsible for the I3C bus initialization. This
> > + *	      initialization should follow the steps described in the I3C
> > + *	      specification. This hook is called with the bus lock held in
> > + *	      write mode, which means all _locked() helpers can safely be
> > + *	      called from there
> > + * @bus_cleanup: cleanup everything done in
> > + *		 &i3c_master_controller_ops->bus_init(). This function is
> > + *		 optional and should only be implemented if
> > + *		 &i3c_master_controller_ops->bus_init() attached private data
> > + *		 to I3C/I2C devices. This hook is called with the bus lock
> > + *		 held in write mode, which means all _locked() helpers can
> > + *		 safely be called from there
> > + * @supports_ccc_cmd: should return true if the CCC command is supported, false
> > + *		      otherwise
> > + * @send_ccc_cmd: send a CCC command
> > + * @send_hdr_cmds: send one or several HDR commands. If there is more than one
> > + *		   command, they should ideally be sent in the same HDR
> > + *		   transaction
> > + * @priv_xfers: do one or several private I3C SDR transfers
> > + * @i2c_xfers: do one or several I2C transfers
> > + * @request_ibi: attach an IBI handler to an I3C device. This implies defining
> > + *		 an IBI handler and the constraints of the IBI (maximum payload
> > + *		 length and number of pre-allocated slots).
> > + *		 Some controllers support less IBI-capable devices than regular
> > + *		 devices, so this method might return -%EBUSY if there's no
> > + *		 more space for an extra IBI registration
> > + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI
> > + *	      should have been disabled with ->disable_irq() prior to that
> > + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called
> > + *		prior to ->enable_ibi(). The controller should first enable
> > + *		the IBI on the controller end (for example, unmask the hardware
> > + *		IRQ) and then send the ENEC CCC command (with the IBI flag set)
> > + *		to the I3C device
> > + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI
> > + *		 flag set and then deactivate the hardware IRQ on the
> > + *		 controller end
> > + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been
> > + *		      processed by its handler. The IBI slot should be put back
> > + *		      in the IBI slot pool so that the controller can re-use it
> > + *		      for a future IBI
> > + *
> > + * One of the most important hooks in these ops is
> > + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of
> > + * things that should be done in &i3c_master_controller_ops->bus_init():
> > + *
> > + * 1) call i3c_master_set_info() with all information describing the master
> > + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC
> > + *    with i3c_master_rstdaa_locked()
> > + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked()
> > + * 4) start a DDA procedure by sending the ENTDAA CCC with
> > + *    i3c_master_entdaa_locked(), or using the internal DAA logic provided by
> > + *    your controller  
> You mean SETDASA CCC command?

No, I really mean ENTDAA and DAA. By internal DAA logic I mean that
some controllers are probably automating the whole DAA procedure, while
others may let the SW control every step.

Thanks for your review.

Boris

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-23 16:56   ` Vitor Soares
  2018-02-23 20:30     ` Boris Brezillon
@ 2018-02-23 22:45     ` Boris Brezillon
  1 sibling, 0 replies; 50+ messages in thread
From: Boris Brezillon @ 2018-02-23 22:45 UTC (permalink / raw)
  To: Vitor Soares
  Cc: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

On Fri, 23 Feb 2018 16:56:14 +0000
Vitor Soares <Vitor.Soares@synopsys.com> wrote:


> > +
> > +/**
> > + * struct i3c_ccc_setda - payload passed to ENTTM CCC
> > + *
> > + * @mode: one of the &enum i3c_ccc_test_mode modes
> > + *
> > + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
> > + * specific test mode.

Oops, copy&paste error. I'll fix the kernel-doc header.

> > + */
> > +struct i3c_ccc_setda {
> > +	u8 addr;
> > +} __packed;  
> 
>  what do you mean with struct? Maybe setdasa? if so, what is the addr?

It's the payload passed to SETDASA and SETNEWDA, hence the generic
_setda suffix. addr is the new dynamic address assigned to the
device.



-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-23 20:30     ` Boris Brezillon
@ 2018-02-26 18:58       ` Vitor Soares
  2018-02-26 20:36         ` Boris Brezillon
  0 siblings, 1 reply; 50+ messages in thread
From: Vitor Soares @ 2018-02-26 18:58 UTC (permalink / raw)
  To: Boris Brezillon, Vitor Soares
  Cc: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

Hi Boris


Às 8:30 PM de 2/23/2018, Boris Brezillon escreveu:
> Hi Vitor,
>
> On Fri, 23 Feb 2018 16:56:14 +0000
> Vitor Soares <Vitor.Soares@synopsys.com> wrote:
>
>> Hi Boris,
>>
>> Às 3:16 PM de 12/14/2017, Boris Brezillon escreveu:
>>> +
>>> +enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus,
>>> +						       u16 addr)
>>> +{
>>> +	int status, bitpos = addr * 2;
>>> +
>>> +	if (addr > I2C_MAX_ADDR)
>>> +		return I3C_ADDR_SLOT_RSVD;
>>> +
>>> +	status = bus->addrslots[bitpos / BITS_PER_LONG];
>>> +	status >>= bitpos % BITS_PER_LONG;
>>> +
>>> +	return status & I3C_ADDR_SLOT_STATUS_MASK;
>>> +}  
>> I don't understand the size of addr. The I3C only allow 7-bit addresses.
>>
>> Is the addrslots used to store the addresses and its status?
> No, slots are used for both I2C and I3C addresses, and an I2C address
> can be 10-bits wide, hence the u16 type.
>
>
> [...]
>
>>> +/**
>>> + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a
>>> + *				specific device
>>> + *
>>> + * @dev: device with which the transfers should be done
>>> + * @xfers: array of transfers
>>> + * @nxfers: number of transfers
>>> + *
>>> + * Initiate one or several private SDR transfers with @dev.
>>> + *
>>> + * This function can sleep and thus cannot be called in atomic context.
>>> + *
>>> + * Return: 0 in case of success, a negative error core otherwise.
>>> + */
>>> +int i3c_device_do_priv_xfers(struct i3c_device *dev,
>>> +			     struct i3c_priv_xfer *xfers,
>>> +			     int nxfers)
>>> +{
>>> +	struct i3c_master_controller *master;
>>> +	int i, ret;
>>> +
>>> +	master = i3c_device_get_master(dev);
>>> +	if (!master)
>>> +		return -EINVAL;
>>> +
>>> +	i3c_bus_normaluse_lock(master->bus);
>>> +	for (i = 0; i < nxfers; i++)
>>> +		xfers[i].addr = dev->info.dyn_addr;
>>> +
>>> +	ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
>>> +	i3c_bus_normaluse_unlock(master->bus);
>>> +
>>> +	return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);  
>>  The controller should know the speed mode for each xfer. The SDR0 mode 
>> is used by default but if any device have read or write speed 
>> limitations the controller can use SDRx.
> I might be wrong, but that's not my understanding of the spec. A device
> can express a speed limitation for SDR priv transfers, but this
> limitation applies to all SDR transfers.
>
> The speed R/W speed limitation is encoded in the device object, so, if
> the controller has to configure that on a per-transfer basis, one
> solution would be to pass the device to the ->priv_xfers().
The speed R/W limitation is only for private transfers. Also the device can have
a limitation to write and not for read data.
This information is obtained with the command GETMXDS which returns the Maximum
Sustained Data Rate for non-CCC messages.
>
>> This could be also applied to i2c transfers.
> Not really. The max SCL frequency is something that applies to the
> whole bus, because all I2C devices have to decode the address when
> messages are sent on the bus to determine if they should ignore or
> process the message.
>
>>> +#endif /* I3C_INTERNAL_H */
>>> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
>>> new file mode 100644
>>> index 000000000000..1c85abac08d5
>>> --- /dev/null
>>> +++ b/drivers/i3c/master.c
>>> @@ -0,0 +1,1433 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
>>> + *
>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
>>> + */
>>> +
>>> +#include <linux/slab.h>
>>> +
>>> +#include "internals.h"
>>> +
>>> +/**
>>> + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
>>> + *				procedure
>>> + * @master: master used to send frames on the bus
>>> + *
>>> + * Send a ENTDAA CCC command to start a DAA procedure.
>>> + *
>>> + * Note that this function only sends the ENTDAA CCC command, all the logic
>>> + * behind dynamic address assignment has to be handled in the I3C master
>>> + * driver.
>>> + *
>>> + * This function must be called with the bus lock held in write mode.
>>> + *
>>> + * Return: 0 in case of success, a negative error code otherwise.
>>> + */
>>> +int i3c_master_entdaa_locked(struct i3c_master_controller *master)
>>> +{
>>> +	struct i3c_ccc_cmd_dest dest = { };
>>> +	struct i3c_ccc_cmd cmd = { };
>>> +	int ret;
>>> +
>>> +	dest.addr = I3C_BROADCAST_ADDR;
>>> +	cmd.dests = &dest;
>>> +	cmd.ndests = 1;
>>> +	cmd.rnw = false;
>>> +	cmd.id = I3C_CCC_ENTDAA;
>>> +
>>> +	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
>>> +	if (ret)
>>> +		return ret;
>>> +
>>> +	return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked);  
>>  can you explain the process?
> Not sure what you mean. The ENTDAA is just a CCC command that is used
> to trigger a DAA procedure. What the master controller does when it
> sends such a command is likely to be controller dependent, and it might
> even be possible that you don't need to call this function in your
> controller driver to trigger a DAA. If you want more details about the
> bus initialization steps and how the ENTDAA CCC command fits into it I
> recommend reading section "5.1.4 Bus Initialization and Dynamic Address
> Assignment Mode"
>
>> the command is only execute once, what if 
>> there is more devices on the bus?
> Again, I'm not sure what you mean. The ENTDAA command is sent every
> time a controller wants to discover new devices on the bus, that can be
> when initializing the bus, after a Hot Join event or simply triggered
> by the user (the last case is not supported yet though).
>
> Now, if you're interested in what happens after an ENTDAA CCC is sent,
> the controller will keep sending RepeatedStart until there's no more
> devices acking the request. You can have a look at "B.3 Error Types in
> Dynamic Address Arbitration" for more details.
My understanding is this command shall be executed once, this mean that only one
slave will assign the dynamic address (cmd.ndests = 1) and not trigger the whole
process of DAA.
Either important is the SETDASA for declared I3C devices. So the DAA process
should start by send an SETDASA and them ENTDAA CCC command.
>>  > +
>>> +/**
>>> + * i3c_master_defslvs_locked() - send a DEFSLVS CCC command
>>> + * @master: master used to send frames on the bus
>>> + *
>>> + * Send a DEFSLVS CCC command containing all the devices known to the @master.
>>> + * This is useful when you have secondary masters on the bus to propagate
>>> + * device information.
>>> + *
>>> + * This should be called after all I3C devices have been discovered (in other
>>> + * words, after the DAA procedure has finished) and instantiated in
>>> + * i3c_master_controller_ops->bus_init().
>>> + * It should also be called if a master ACKed an Hot-Join request and assigned
>>> + * a dynamic address to the device joining the bus.
>>> + *
>>> + * This function must be called with the bus lock held in write mode.
>>> + *
>>> + * Return: 0 in case of success, a negative error code otherwise.
>>> + */
>>> +int i3c_master_defslvs_locked(struct i3c_master_controller *master)
>>> +{
>>> +	struct i3c_ccc_cmd_dest dest = {
>>> +		.addr = I3C_BROADCAST_ADDR,
>>> +	};
>>> +	struct i3c_ccc_cmd cmd = {
>>> +		.id = I3C_CCC_DEFSLVS,
>>> +		.dests = &dest,
>>> +		.ndests = 1,
>>> +	};
>>> +	struct i3c_ccc_defslvs *defslvs;
>>> +	struct i3c_ccc_dev_desc *desc;
>>> +	struct i3c_device *i3cdev;
>>> +	struct i2c_device *i2cdev;
>>> +	struct i3c_bus *bus;
>>> +	bool send = false;
>>> +	int ndevs = 0, ret;
>>> +
>>> +	if (!master)
>>> +		return -EINVAL;
>>> +
>>> +	bus = i3c_master_get_bus(master);
>>> +	i3c_bus_for_each_i3cdev(bus, i3cdev) {
>>> +		ndevs++;
>>> +		if (I3C_BCR_DEVICE_ROLE(i3cdev->info.bcr) == I3C_BCR_I3C_MASTER)
>>> +			send = true;
>>> +	}
>>> +
>>> +	/* No other master on the bus, skip DEFSLVS. */
>>> +	if (!send)
>>> +		return 0;
>>> +
>>> +	i3c_bus_for_each_i2cdev(bus, i2cdev)
>>> +		ndevs++;
>>> +
>>> +	dest.payload.len = sizeof(*defslvs) +
>>> +			   ((ndevs - 1) * sizeof(struct i3c_ccc_dev_desc));
>>> +	defslvs = kzalloc(dest.payload.len, GFP_KERNEL);
>>> +	if (!defslvs)
>>> +		return -ENOMEM;
>>> +
>>> +	dest.payload.data = defslvs;
>>> +
>>> +	defslvs->count = ndevs;
>>> +	defslvs->master.bcr = master->this->info.bcr;
>>> +	defslvs->master.dcr = master->this->info.dcr;
>>> +	defslvs->master.dyn_addr = master->this->info.dyn_addr;
>>> +	defslvs->master.static_addr = I3C_BROADCAST_ADDR;  
>>  Why defslvs->master.static_addr = I3C_BROADCAST_ADDR?
> I just follow what's document in "5.1.9.3.7 Define List of Slaves
> (DEFSLVS)"
yes, that's right.
>>  > +
>>> +	desc = defslvs->slaves;
>>> +	i3c_bus_for_each_i2cdev(bus, i2cdev) {
>>> +		desc->lvr = i2cdev->lvr;
>>> +		desc->static_addr = i2cdev->info.addr;
>>> +		desc++;
>>> +	}
>>> +
>>> +	i3c_bus_for_each_i3cdev(bus, i3cdev) {
>>> +		/* Skip the I3C dev representing this master. */
>>> +		if (i3cdev == master->this)
>>> +			continue;
>>> +
>>> +		desc->bcr = i3cdev->info.bcr;
>>> +		desc->dcr = i3cdev->info.dcr;
>>> +		desc->dyn_addr = i3cdev->info.dyn_addr;
>>> +		desc->static_addr = i3cdev->info.static_addr;
>>> +		desc++;
>>> +	}
>>> +
>>> +	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
>>> +	kfree(defslvs);
>>> +
>>> +	return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(i3c_master_defslvs_locked);
>>> +
>>> +
>>> +static int i3c_master_i2c_adapter_xfer(struct i2c_adapter *adap,
>>> +				       struct i2c_msg *xfers, int nxfers)
>>> +{
>>> +	struct i3c_master_controller *master = i2c_adapter_to_i3c_master(adap);
>>> +	int i, ret;
>>> +
>>> +	for (i = 0; i < nxfers; i++) {
>>> +		enum i3c_addr_slot_status status;
>>> +
>>> +		status = i3c_bus_get_addr_slot_status(master->bus,
>>> +						      xfers[i].addr);
>>> +		if (status != I3C_ADDR_SLOT_I2C_DEV)
>>> +			return -EINVAL;
>>> +	}
>>> +
>>> +	ret = i3c_master_do_i2c_xfers(master, xfers, nxfers);
>>> +	if (ret)
>>> +		return ret;
>>> +
>>> +	return nxfers;
>>> +}
>>> +
>>> +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap)
>>> +{
>>> +	return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR;
>>> +}  
>>  Is I2C_FUNC_10BIT_ADDR allowed ?
> According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes (at
> least that my understanding). And the Cadence controller supports it.
The table say the oposite. The I2C extended address feature is not used on I3C
bus, thus this feature shall be disable.
BTW it is optional on I2C devices.

>
>>  > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
>>> new file mode 100644
>>> index 000000000000..e69de29bb2d1
>>> diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
>>> new file mode 100644
>>> index 000000000000..e69de29bb2d1
>>> diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h
>>> new file mode 100644
>>> index 000000000000..ff3e1a3e2c4c
>>> --- /dev/null
>>> +++ b/include/linux/i3c/ccc.h
>>> @@ -0,0 +1,380 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
>>> + *
>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
>>> + */
>>> +
>>> +
>>> +/**
>>> + * enum i3c_ccc_test_mode - enum listing all available test modes
>>> + *
>>> + * @I3C_CCC_EXIT_TEST_MODE: exit test mode
>>> + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode
>>> + */
>>> +enum i3c_ccc_test_mode {
>>> +	I3C_CCC_EXIT_TEST_MODE,
>>> +	I3C_CCC_VENDOR_TEST_MODE,
>>> +};
>>> +
>>> +/**
>>> + * struct i3c_ccc_enttm - payload passed to ENTTM CCC
>>> + *
>>> + * @mode: one of the &enum i3c_ccc_test_mode modes
>>> + *
>>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
>>> + * specific test mode.
>>> + */
>>> +struct i3c_ccc_enttm {
>>> +	u8 mode;
>>> +} __packed;
>>> +
>>> +/**
>>> + * struct i3c_ccc_setda - payload passed to ENTTM CCC
>>> + *
>>> + * @mode: one of the &enum i3c_ccc_test_mode modes
>>> + *
>>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
>>> + * specific test mode.
>>> + */
>>> +struct i3c_ccc_setda {
>>> +	u8 addr;
>>> +} __packed;  
>>  what do you mean with struct? Maybe setdasa? if so, what is the addr?
Do you have the function to use this structure? Because one command use the
static address and the other use the dynamic address.

>>
>>  > +/**
>>> + * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers
>>> + */
>>> +enum i3c_sdr_max_data_rate {
>>> +	I3C_SDR_DR_FSCL_MAX,
>>> +	I3C_SDR_DR_FSCL_8MHZ,
>>> +	I3C_SDR_DR_FSCL_6MHZ,
>>> +	I3C_SDR_DR_FSCL_4MHZ,
>>> +	I3C_SDR_DR_FSCL_2MHZ,
>>> +};  
>> Can you change the names to:
>>
>> I3C_SDR0_FSCL_MAX,
>> I3C_SDR1_FSCL_8MHZ,
>> I3C_SDR2_FSCL_6MHZ,
>> I3C_SDR3_FSCL_4MHZ,
>> I3C_SDR4_FSCL_2MHZ,
>>
>> thus the data rate isn't repeated.
> What's the problem with the name I use? Moreover, I see no mention to
> the SDR0,1,2,3,4 modes in the public spec.
When you get the GETMXDS information, the maxWr and maxRd came from 0 to 4, so
in my opinion I think in this way is easier to have a relationship.
>
>>> +
>>> +/**
>>> + * enum i3c_tsco - clock to data turn-around
>>> + */
>>> +enum i3c_tsco {
>>> +	I3C_TSCO_LT_8NS,
>>> +	I3C_TSCO_LT_9NS,
>>> +	I3C_TSCO_LT_10NS,
>>> +	I3C_TSCO_LT_11NS,
>>> +	I3C_TSCO_LT_12NS,
>>> +};  
>> what's the meaning of _LT_ ?
> This I don't remember. I'll drop it in the next version.
>
>>> +
>>> +#endif /* I3C_CCC_H */
>>> diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h
>>> new file mode 100644
>>> index 000000000000..83958d3a02e2
>>> --- /dev/null
>>> +++ b/include/linux/i3c/device.h
>>> @@ -0,0 +1,321 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
>>> + *
>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
>>> + */
>>> +
>>> +#ifndef I3C_DEV_H
>>> +#define I3C_DEV_H
>>> +
>>> +#include <linux/device.h>
>>> +#include <linux/i2c.h>
>>> +#include <linux/mod_devicetable.h>
>>> +#include <linux/module.h>
>>> +
>>> +/**
>>> + * enum i3c_hdr_mode - HDR mode ids
>>> + * @I3C_HDR_DDR: DDR mode
>>> + * @I3C_HDR_TSP: TSP mode
>>> + * @I3C_HDR_TSL: TSL mode
>>> + */
>>> +enum i3c_hdr_mode {
>>> +	I3C_HDR_DDR,
>>> +	I3C_HDR_TSP,
>>> +	I3C_HDR_TSL,
>>> +};
>>> +
>>> +/**
>>> + * struct i3c_hdr_cmd - I3C HDR command
>>> + * @mode: HDR mode selected for this command
>>> + * @code: command opcode
>>> + * @addr: I3C dynamic address
>>> + * @ndatawords: number of data words (a word is 16bits wide)
>>> + * @data: input/output buffer
>>> + */
>>> +struct i3c_hdr_cmd {
>>> +	enum i3c_hdr_mode mode;
>>> +	u8 code;
>>> +	u8 addr;
>>> +	int ndatawords;
>>> +	union {
>>> +		u16 *in;
>>> +		const u16 *out;
>>> +	} data;
>>> +};
Please mention that the @code is what will define if the transfer is read or write.
>>> +
>>> +/* Private SDR read transfer */
>>> +#define I3C_PRIV_XFER_READ		BIT(0)
>>> +/*
>>> + * Instruct the controller to issue a STOP after a specific transfer instead
>>> + * of a REPEATED START.
>>> + */
>>> +#define I3C_PRIV_XFER_STOP		BIT(1)
>>> +
>>> +/**
>>> + * struct i3c_priv_xfer - I3C SDR private transfer
>>> + * @addr: I3C dynamic address
>>> + * @len: transfer length in bytes of the transfer
>>> + * @flags: combination of I3C_PRIV_XFER_xxx flags
>>> + * @data: input/output buffer
>>> + */
>>> +struct i3c_priv_xfer {
>>> +	u8 addr;
>>> +	u16 len;
>>> +	u32 flags;
>>> +	struct {
>>> +		void *in;
>>> +		const void *out;
>>> +	} data;
>>> +};  
>>  Same as above, i3c_sdr_max_data_rate to change the bus scl.
> If I'm understanding the spec correctly, that's not something you want
> to change on a per-transfer basis. The constraint is on the device
> itself and should IMO not be part of the i3c_priv_xfer struct.
As mention before this is important.
You can do the same as for struct i3c_hdr_cmd and add a enum i3c_sdr_max_data_rate.

The @flag only have 2 bits of load, is the rest opened?
>
>>  > +
>>> +/**
>>> + * enum i3c_dcr - I3C DCR values
>>> + * @I3C_DCR_GENERIC_DEVICE: generic I3C device
>>> + */
>>> +enum i3c_dcr {
>>> +	I3C_DCR_GENERIC_DEVICE = 0,
>>> +};
>>> +
>>> +#define I3C_PID_MANUF_ID(pid)		(((pid) & GENMASK_ULL(47, 33)) >> 33)
>>> +#define I3C_PID_RND_LOWER_32BITS(pid)	(!!((pid) & BIT_ULL(32)))
>>> +#define I3C_PID_RND_VAL(pid)		((pid) & GENMASK_ULL(31, 0))
>>> +#define I3C_PID_PART_ID(pid)		(((pid) & GENMASK_ULL(31, 16)) >> 16)
>>> +#define I3C_PID_INSTANCE_ID(pid)	(((pid) & GENMASK_ULL(15, 12)) >> 12)
>>> +#define I3C_PID_EXTRA_INFO(pid)		((pid) & GENMASK_ULL(11, 0))
>>> +
>>> +#define I3C_BCR_DEVICE_ROLE(bcr)	((bcr) & GENMASK(7, 6))
>>> +#define I3C_BCR_I3C_SLAVE		(0 << 6)
>>> +#define I3C_BCR_I3C_MASTER		(1 << 6)
>>> +#define I3C_BCR_HDR_CAP			BIT(5)
>>> +#define I3C_BCR_BRIDGE			BIT(4)
>>> +#define I3C_BCR_OFFLINE_CAP		BIT(3)
>>> +#define I3C_BCR_IBI_PAYLOAD		BIT(2)
>>> +#define I3C_BCR_IBI_REQ_CAP		BIT(1)
>>> +#define I3C_BCR_MAX_DATA_SPEED_LIM	BIT(0)
>>> +
>>> +/**
>>> + * struct i3c_device_info - I3C device information
>>> + * @pid: Provisional ID
>>> + * @bcr: Bus Characteristic Register
>>> + * @dcr: Device Characteristic Register
>>> + * @static_addr: static/I2C address
>>> + * @dyn_addr: dynamic address
>>> + * @hdr_cap: supported HDR modes
>>> + * @max_read_ds: max read speed information
>>> + * @max_write_ds: max write speed information
>>> + * @max_ibi_len: max IBI payload length
>>> + * @max_read_turnaround: max read turn-around time in micro-seconds
>>> + * @max_read_len: max private SDR read length in bytes
>>> + * @max_write_len: max private SDR write length in bytes
>>> + *
>>> + * These are all basic information that should be advertised by an I3C device.
>>> + * Some of them are optional depending on the device type and device
>>> + * capabilities.
>>> + * For each I3C slave attached to a master with
>>> + * i3c_master_add_i3c_dev_locked(), the core will send the relevant CCC command
>>> + * to retrieve these data.
>>> + */
>>> +struct i3c_device_info {
>>> +	u64 pid;
>>> +	u8 bcr;
>>> +	u8 dcr;
>>> +	u8 static_addr;
>>> +	u8 dyn_addr;
>>> +	u8 hdr_cap;
>>> +	u8 max_read_ds;
>>> +	u8 max_write_ds;
>>> +	u8 max_ibi_len;
>>> +	u32 max_read_turnaround;
>>> +	u16 max_read_len;
>>> +	u16 max_write_len;
>>> +};
>>> +  
>>  is this information filled with data provided from CCC commands?
> Yes, they are.
Ok, them the intention is to do this on bus_init(), right?
>
>>  > +
>>> +#endif /* I3C_DEV_H */
>>> diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
>>> new file mode 100644
>>> index 000000000000..7ec9a4821bac
>>> --- /dev/null
>>> +++ b/include/linux/i3c/master.h
>>> @@ -0,0 +1,564 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
>>> + *
>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
>>> + */
>>> +
>>> +#ifndef I3C_MASTER_H
>>> +#define I3C_MASTER_H
>>> +
>>> +#include <linux/i2c.h>
>>> +#include <linux/i3c/ccc.h>
>>> +#include <linux/i3c/device.h>
>>> +#include <linux/spinlock.h>
>>> +
>>> +#define I3C_HOT_JOIN_ADDR		0x2
>>> +#define I3C_BROADCAST_ADDR		0x7e
>>> +#define I3C_MAX_ADDR			GENMASK(6, 0)
>>> +
>>> +struct i3c_master_controller;
>>> +struct i3c_bus;
>>> +
>>> +/**
>>> + * struct i3c_i2c_dev - I3C/I2C common information
>>> + * @node: node element used to insert the device into the I2C or I3C device
>>> + *	  list
>>> + * @bus: I3C bus this device is connected to
>>> + * @master: I3C master that instantiated this device. Will be used to send
>>> + *	    I2C/I3C frames on the bus
>>> + * @master_priv: master private data assigned to the device. Can be used to
>>> + *		 add master specific information
>>> + *
>>> + * This structure is describing common I3C/I2C dev information.
>>> + */
>>> +struct i3c_i2c_dev {
>>> +	struct list_head node;
>>> +	struct i3c_bus *bus;
>>> +	struct i3c_master_controller *master;
>>> +	void *master_priv;
>>> +};
>>> +
>>> +#define I3C_LVR_I2C_INDEX_MASK		GENMASK(7, 5)
>>> +#define I3C_LVR_I2C_INDEX(x)		((x) << 5)
>>> +#define I3C_LVR_I2C_FM_MODE		BIT(4)
>>> +
>>> +#define I2C_MAX_ADDR			GENMASK(9, 0)  
>>  why 10-bit address?
>>
> Because some I2C devices have 10-bit addresses.
>
>>  > +
>>> +/**
>>> + * struct i2c_device - I2C device object
>>> + * @common: inherit common I3C/I2C description
>>> + * @info: I2C board info used to instantiate the I2C device. If you are
>>> + *	  using DT to describe your hardware, this will be filled for you
>>> + * @client: I2C client object created by the I2C framework. This will only
>>> + *	    be valid after i3c_master_register() returns
>>> + * @lvr: Legacy Virtual Register value as described in the I3C specification
>>> + *
>>> + * I2C device object. Note that the real I2C device is represented by
>>> + * i2c_device->client, but we need extra information to handle the device when
>>> + * it's connected to an I3C bus, hence the &struct i2c_device wrapper.
>>> + *
>>> + * The I2C framework is not impacted by this new representation.
>>> + */
>>> +struct i2c_device {
>>> +	struct i3c_i2c_dev common;
>>> +	struct i2c_board_info info;
>>> +	struct i2c_client *client;
>>> +	u8 lvr;
>>> +};
>>> +  
>>  It is usefull to know the speed limitations of the device.
> See my previous explanation about I2C and the max frequency. BTW, the
> FM vs FM+ information is already encoded in the ->lvr field.
you are right.
>>  > +
>>> +/**
>>> + * enum i3c_addr_slot_status - I3C address slot status
>>> + * @I3C_ADDR_SLOT_FREE: address is free
>>> + * @I3C_ADDR_SLOT_RSVD: address is reserved
>>> + * @I3C_ADDR_SLOT_I2C_DEV: address is assigned to an I2C device
>>> + * @I3C_ADDR_SLOT_I3C_DEV: address is assigned to an I3C device
>>> + * @I3C_ADDR_SLOT_STATUS_MASK: address slot mask
>>> + *
>>> + * On an I3C bus, addresses are assigned dynamically, and we need to know which
>>> + * addresses are free to use and which ones are already assigned.
>>> + *
>>> + * Addresses marked as reserved are those reserved by the I3C protocol
>>> + * (broadcast address, ...).
>>> + */
>>> +enum i3c_addr_slot_status {
>>> +	I3C_ADDR_SLOT_FREE,
>>> +	I3C_ADDR_SLOT_RSVD,
>>> +	I3C_ADDR_SLOT_I2C_DEV,
>>> +	I3C_ADDR_SLOT_I3C_DEV,
>>> +	I3C_ADDR_SLOT_STATUS_MASK = 3,
>>> +};
>>> +
>>> +/**
>>> + * struct i3c_bus - I3C bus object
>>> + * @dev: device to be registered to the device-model
>>> + * @cur_master: I3C master currently driving the bus. Since I3C is multi-master
>>> + *		this can change over the time. Will be used to let a master
>>> + *		know whether it needs to request bus ownership before sending
>>> + *		a frame or not
>>> + * @id: bus ID. Assigned by the framework when register the bus
>>> + * @addrslots: a bitmap with 2-bits per-slot to encode the address status and
>>> + *	       ease the DAA (Dynamic Address Assignment) procedure (see
>>> + *	       &enum i3c_addr_slot_status)
>>> + * @mode: bus mode (see &enum i3c_bus_mode)
>>> + * @scl_rate: SCL signal rate for I3C and I2C mode
>>> + * @devs: 2 lists containing all I3C/I2C devices connected to the bus
>>> + * @lock: read/write lock on the bus. This is needed to protect against
>>> + *	  operations that have an impact on the whole bus and the devices
>>> + *	  connected to it. For example, when asking slaves to drop their
>>> + *	  dynamic address (RSTDAA CCC), we need to make sure no one is trying
>>> + *	  to send I3C frames to these devices.
>>> + *	  Note that this lock does not protect against concurrency between
>>> + *	  devices: several drivers can send different I3C/I2C frames through
>>> + *	  the same master in parallel. This is the responsibility of the
>>> + *	  master to guarantee that frames are actually sent sequentially and
>>> + *	  not interlaced
>>> + *
>>> + * The I3C bus is represented with its own object and not implicitly described
>>> + * by the I3C master to cope with the multi-master functionality, where one bus
>>> + * can be shared amongst several masters, each of them requesting bus ownership
>>> + * when they need to.
>>> + */
>>> +struct i3c_bus {
>>> +	struct device dev;
>>> +	struct i3c_device *cur_master;
>>> +	int id;
>>> +	unsigned long addrslots[((I2C_MAX_ADDR + 1) * 2) / BITS_PER_LONG];
>>> +	enum i3c_bus_mode mode;
>>> +	struct {
>>> +		unsigned long i3c;
>>> +		unsigned long i2c;
>>> +	} scl_rate;
>>> +	struct {
>>> +		struct list_head i3c;
>>> +		struct list_head i2c;
>>> +	} devs;
>>> +	struct rw_semaphore lock;
>>> +};  
>> Can you explain the addrslots[] ?
> It's a bitmap encoding the status of I3C/I2C addresses: are they
> assigned, reserved of free, and if they are assigned is it an I3C or
> I2C device. That's particularly useful to master controller drivers
> to know which addresses they can assign during DAA.
>
> I'll try to clarify it in the kernel-doc header.
yes please.
>
>>> +
>>> +static inline struct i3c_device *dev_to_i3cdev(struct device *dev)
>>> +{
>>> +	return container_of(dev, struct i3c_device, dev);
>>> +}
>>> +
>>> +struct i3c_master_controller;
>>> +
>>> +/**
>>> + * struct i3c_master_controller_ops - I3C master methods
>>> + * @bus_init: hook responsible for the I3C bus initialization. This
>>> + *	      initialization should follow the steps described in the I3C
>>> + *	      specification. This hook is called with the bus lock held in
>>> + *	      write mode, which means all _locked() helpers can safely be
>>> + *	      called from there
>>> + * @bus_cleanup: cleanup everything done in
>>> + *		 &i3c_master_controller_ops->bus_init(). This function is
>>> + *		 optional and should only be implemented if
>>> + *		 &i3c_master_controller_ops->bus_init() attached private data
>>> + *		 to I3C/I2C devices. This hook is called with the bus lock
>>> + *		 held in write mode, which means all _locked() helpers can
>>> + *		 safely be called from there
>>> + * @supports_ccc_cmd: should return true if the CCC command is supported, false
>>> + *		      otherwise
>>> + * @send_ccc_cmd: send a CCC command
>>> + * @send_hdr_cmds: send one or several HDR commands. If there is more than one
>>> + *		   command, they should ideally be sent in the same HDR
>>> + *		   transaction
>>> + * @priv_xfers: do one or several private I3C SDR transfers
>>> + * @i2c_xfers: do one or several I2C transfers
>>> + * @request_ibi: attach an IBI handler to an I3C device. This implies defining
>>> + *		 an IBI handler and the constraints of the IBI (maximum payload
>>> + *		 length and number of pre-allocated slots).
>>> + *		 Some controllers support less IBI-capable devices than regular
>>> + *		 devices, so this method might return -%EBUSY if there's no
>>> + *		 more space for an extra IBI registration
>>> + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI
>>> + *	      should have been disabled with ->disable_irq() prior to that
>>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called
>>> + *		prior to ->enable_ibi(). The controller should first enable
>>> + *		the IBI on the controller end (for example, unmask the hardware
>>> + *		IRQ) and then send the ENEC CCC command (with the IBI flag set)
>>> + *		to the I3C device
>>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI
>>> + *		 flag set and then deactivate the hardware IRQ on the
>>> + *		 controller end
>>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been
>>> + *		      processed by its handler. The IBI slot should be put back
>>> + *		      in the IBI slot pool so that the controller can re-use it
>>> + *		      for a future IBI
>>> + *
>>> + * One of the most important hooks in these ops is
>>> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of
>>> + * things that should be done in &i3c_master_controller_ops->bus_init():
>>> + *
>>> + * 1) call i3c_master_set_info() with all information describing the master
>>> + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC
>>> + *    with i3c_master_rstdaa_locked()
>>> + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked()
>>> + * 4) start a DDA procedure by sending the ENTDAA CCC with
>>> + *    i3c_master_entdaa_locked(), or using the internal DAA logic provided by
>>> + *    your controller  
>> You mean SETDASA CCC command?
> No, I really mean ENTDAA and DAA. By internal DAA logic I mean that
> some controllers are probably automating the whole DAA procedure, while
> others may let the SW control every step.
My understanding is that i3c_master_entdaa_locked() will trigger the DAA process
and DAA can be done by SETDASA, ENTDAA and later after the bus initialization
with SETNEWDA.

I think the DAA process should be more generic, right now is only made through
the ENTDAA command with (cmd.ndests = 1).
I mean, shouldn't this be made by the core? First doing DAA for the devices
declared and them try do discover the rest of devices on the bus. 
>
> Thanks for your review.
>
> Boris
>

Thank you,
Vitor Soares

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-26 18:58       ` Vitor Soares
@ 2018-02-26 20:36         ` Boris Brezillon
  2018-02-26 20:40           ` Boris Brezillon
  2018-02-27 16:03           ` Vitor Soares
  0 siblings, 2 replies; 50+ messages in thread
From: Boris Brezillon @ 2018-02-26 20:36 UTC (permalink / raw)
  To: Vitor Soares
  Cc: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

Hi Vitor,

On Mon, 26 Feb 2018 18:58:15 +0000
Vitor Soares <Vitor.Soares@synopsys.com> wrote:

> >>> +/**
> >>> + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a
> >>> + *				specific device
> >>> + *
> >>> + * @dev: device with which the transfers should be done
> >>> + * @xfers: array of transfers
> >>> + * @nxfers: number of transfers
> >>> + *
> >>> + * Initiate one or several private SDR transfers with @dev.
> >>> + *
> >>> + * This function can sleep and thus cannot be called in atomic context.
> >>> + *
> >>> + * Return: 0 in case of success, a negative error core otherwise.
> >>> + */
> >>> +int i3c_device_do_priv_xfers(struct i3c_device *dev,
> >>> +			     struct i3c_priv_xfer *xfers,
> >>> +			     int nxfers)
> >>> +{
> >>> +	struct i3c_master_controller *master;
> >>> +	int i, ret;
> >>> +
> >>> +	master = i3c_device_get_master(dev);
> >>> +	if (!master)
> >>> +		return -EINVAL;
> >>> +
> >>> +	i3c_bus_normaluse_lock(master->bus);
> >>> +	for (i = 0; i < nxfers; i++)
> >>> +		xfers[i].addr = dev->info.dyn_addr;
> >>> +
> >>> +	ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
> >>> +	i3c_bus_normaluse_unlock(master->bus);
> >>> +
> >>> +	return ret;
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);    
> >>  The controller should know the speed mode for each xfer. The SDR0 mode 
> >> is used by default but if any device have read or write speed 
> >> limitations the controller can use SDRx.  
> > I might be wrong, but that's not my understanding of the spec. A device
> > can express a speed limitation for SDR priv transfers, but this
> > limitation applies to all SDR transfers.
> >
> > The speed R/W speed limitation is encoded in the device object, so, if
> > the controller has to configure that on a per-transfer basis, one
> > solution would be to pass the device to the ->priv_xfers().  
> The speed R/W limitation is only for private transfers. Also the device can have
> a limitation to write and not for read data.
> This information is obtained with the command GETMXDS which returns the Maximum
> Sustained Data Rate for non-CCC messages.

And that's exactly what I expose in i3c_device_info, which is embedded
in i3c_device, so you should have all the information you need to
determine the speed in the controller driver if ->priv_xfer() is passed
the device attached to those transfers. Would that be okay if we pass an
i3c_device object to ->priv_xfers()?

> >  
> >> This could be also applied to i2c transfers.  
> > Not really. The max SCL frequency is something that applies to the
> > whole bus, because all I2C devices have to decode the address when
> > messages are sent on the bus to determine if they should ignore or
> > process the message.
> >  
> >>> +#endif /* I3C_INTERNAL_H */
> >>> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> >>> new file mode 100644
> >>> index 000000000000..1c85abac08d5
> >>> --- /dev/null
> >>> +++ b/drivers/i3c/master.c
> >>> @@ -0,0 +1,1433 @@
> >>> +// SPDX-License-Identifier: GPL-2.0
> >>> +/*
> >>> + * Copyright (C) 2017 Cadence Design Systems Inc.
> >>> + *
> >>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> >>> + */
> >>> +
> >>> +#include <linux/slab.h>
> >>> +
> >>> +#include "internals.h"
> >>> +
> >>> +/**
> >>> + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
> >>> + *				procedure
> >>> + * @master: master used to send frames on the bus
> >>> + *
> >>> + * Send a ENTDAA CCC command to start a DAA procedure.
> >>> + *
> >>> + * Note that this function only sends the ENTDAA CCC command, all the logic
> >>> + * behind dynamic address assignment has to be handled in the I3C master
> >>> + * driver.
> >>> + *
> >>> + * This function must be called with the bus lock held in write mode.
> >>> + *
> >>> + * Return: 0 in case of success, a negative error code otherwise.
> >>> + */
> >>> +int i3c_master_entdaa_locked(struct i3c_master_controller *master)
> >>> +{
> >>> +	struct i3c_ccc_cmd_dest dest = { };
> >>> +	struct i3c_ccc_cmd cmd = { };
> >>> +	int ret;
> >>> +
> >>> +	dest.addr = I3C_BROADCAST_ADDR;
> >>> +	cmd.dests = &dest;
> >>> +	cmd.ndests = 1;
> >>> +	cmd.rnw = false;
> >>> +	cmd.id = I3C_CCC_ENTDAA;
> >>> +
> >>> +	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
> >>> +	if (ret)
> >>> +		return ret;
> >>> +
> >>> +	return 0;
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked);    
> >>  can you explain the process?  
> > Not sure what you mean. The ENTDAA is just a CCC command that is used
> > to trigger a DAA procedure. What the master controller does when it
> > sends such a command is likely to be controller dependent, and it might
> > even be possible that you don't need to call this function in your
> > controller driver to trigger a DAA. If you want more details about the
> > bus initialization steps and how the ENTDAA CCC command fits into it I
> > recommend reading section "5.1.4 Bus Initialization and Dynamic Address
> > Assignment Mode"
> >  
> >> the command is only execute once, what if 
> >> there is more devices on the bus?  
> > Again, I'm not sure what you mean. The ENTDAA command is sent every
> > time a controller wants to discover new devices on the bus, that can be
> > when initializing the bus, after a Hot Join event or simply triggered
> > by the user (the last case is not supported yet though).
> >
> > Now, if you're interested in what happens after an ENTDAA CCC is sent,
> > the controller will keep sending RepeatedStart until there's no more
> > devices acking the request. You can have a look at "B.3 Error Types in
> > Dynamic Address Arbitration" for more details.  
> My understanding is this command shall be executed once, this mean that only one
> slave will assign the dynamic address (cmd.ndests = 1) and not trigger the whole
> process of DAA.

No, that's not what happens. The master controller is supposed to
continue until no one replies with an Ack on the bus, and by continue I
don't mean resend an ENTDAA, but issue a RepeatedStart followed by the
broadcast address (0x7e).

> Either important is the SETDASA for declared I3C devices. So the DAA process
> should start by send an SETDASA and them ENTDAA CCC command.

My understanding was that SETDASA was not mandatory, and was only useful
when one wants to assign a specific dynamic address to a slave that has
a static address (which is again not mandatory).
I've tested it, and even devices with a static address participate to
the DAA procedure if they've not been assigned a dynamic address yet,
so I don't see the need for this SETDASA step if you don't need to
assign a particular dynamic address to the device.

Could you tell me why you think SETDASA is required?

> >>> +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap)
> >>> +{
> >>> +	return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR;
> >>> +}    
> >>  Is I2C_FUNC_10BIT_ADDR allowed ?  
> > According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes (at
> > least that my understanding). And the Cadence controller supports it.  
> The table say the oposite. The I2C extended address feature is not used on I3C
> bus, thus this feature shall be disable.

Actually, I was wrong when initially mentioning this table: it's about
I2C features supported on I3C slaves, so not really what we're looking
for. Here, we're wondering if I2C-only devices can have 10-bit
addresses. The Cadence controller supports that, so there's probably
nothing preventing use of 10-bit addresses for I2C transfers, but maybe
not all I3C master controllers support that, so we should probably
let the I3C master driver implement this method.

> BTW it is optional on I2C devices.

You mean I2C controllers? When an I2C device has a 10bit address, the
controller has to support this mode to communicate with the device, at
least that's my understanding. But we're digressing a bit. The
question is not whether I2C devices can optionally use a 10 bit
address, but whether I3C master controller can support this mode for
I2C transfers to I2C-only devices.

> 
> >  
> >>  > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
> >>> new file mode 100644
> >>> index 000000000000..e69de29bb2d1
> >>> diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
> >>> new file mode 100644
> >>> index 000000000000..e69de29bb2d1
> >>> diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h
> >>> new file mode 100644
> >>> index 000000000000..ff3e1a3e2c4c
> >>> --- /dev/null
> >>> +++ b/include/linux/i3c/ccc.h
> >>> @@ -0,0 +1,380 @@
> >>> +/* SPDX-License-Identifier: GPL-2.0 */
> >>> +/*
> >>> + * Copyright (C) 2017 Cadence Design Systems Inc.
> >>> + *
> >>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> >>> + */
> >>> +
> >>> +
> >>> +/**
> >>> + * enum i3c_ccc_test_mode - enum listing all available test modes
> >>> + *
> >>> + * @I3C_CCC_EXIT_TEST_MODE: exit test mode
> >>> + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode
> >>> + */
> >>> +enum i3c_ccc_test_mode {
> >>> +	I3C_CCC_EXIT_TEST_MODE,
> >>> +	I3C_CCC_VENDOR_TEST_MODE,
> >>> +};
> >>> +
> >>> +/**
> >>> + * struct i3c_ccc_enttm - payload passed to ENTTM CCC
> >>> + *
> >>> + * @mode: one of the &enum i3c_ccc_test_mode modes
> >>> + *
> >>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
> >>> + * specific test mode.
> >>> + */
> >>> +struct i3c_ccc_enttm {
> >>> +	u8 mode;
> >>> +} __packed;
> >>> +
> >>> +/**
> >>> + * struct i3c_ccc_setda - payload passed to ENTTM CCC
> >>> + *
> >>> + * @mode: one of the &enum i3c_ccc_test_mode modes
> >>> + *
> >>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
> >>> + * specific test mode.
> >>> + */
> >>> +struct i3c_ccc_setda {
> >>> +	u8 addr;
> >>> +} __packed;    
> >>  what do you mean with struct? Maybe setdasa? if so, what is the addr?  
> Do you have the function to use this structure? Because one command use the
> static address and the other use the dynamic address.
> 
> >>  
> >>  > +/**
> >>> + * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers
> >>> + */
> >>> +enum i3c_sdr_max_data_rate {
> >>> +	I3C_SDR_DR_FSCL_MAX,
> >>> +	I3C_SDR_DR_FSCL_8MHZ,
> >>> +	I3C_SDR_DR_FSCL_6MHZ,
> >>> +	I3C_SDR_DR_FSCL_4MHZ,
> >>> +	I3C_SDR_DR_FSCL_2MHZ,
> >>> +};    
> >> Can you change the names to:
> >>
> >> I3C_SDR0_FSCL_MAX,
> >> I3C_SDR1_FSCL_8MHZ,
> >> I3C_SDR2_FSCL_6MHZ,
> >> I3C_SDR3_FSCL_4MHZ,
> >> I3C_SDR4_FSCL_2MHZ,
> >>
> >> thus the data rate isn't repeated.  
> > What's the problem with the name I use? Moreover, I see no mention to
> > the SDR0,1,2,3,4 modes in the public spec.  
> When you get the GETMXDS information, the maxWr and maxRd came from 0 to 4, so
> in my opinion I think in this way is easier to have a relationship.

It's an emum, and there's no mention of the SDRX modes you're using
here in the I3C spec. I guess it's named this way in your I3C
controller datasheet. I personally don't see a good reason to add SDRX
in the name, but if you insist...

> >>> +
> >>> +#endif /* I3C_CCC_H */
> >>> diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h
> >>> new file mode 100644
> >>> index 000000000000..83958d3a02e2
> >>> --- /dev/null
> >>> +++ b/include/linux/i3c/device.h
> >>> @@ -0,0 +1,321 @@
> >>> +/* SPDX-License-Identifier: GPL-2.0 */
> >>> +/*
> >>> + * Copyright (C) 2017 Cadence Design Systems Inc.
> >>> + *
> >>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> >>> + */
> >>> +
> >>> +#ifndef I3C_DEV_H
> >>> +#define I3C_DEV_H
> >>> +
> >>> +#include <linux/device.h>
> >>> +#include <linux/i2c.h>
> >>> +#include <linux/mod_devicetable.h>
> >>> +#include <linux/module.h>
> >>> +
> >>> +/**
> >>> + * enum i3c_hdr_mode - HDR mode ids
> >>> + * @I3C_HDR_DDR: DDR mode
> >>> + * @I3C_HDR_TSP: TSP mode
> >>> + * @I3C_HDR_TSL: TSL mode
> >>> + */
> >>> +enum i3c_hdr_mode {
> >>> +	I3C_HDR_DDR,
> >>> +	I3C_HDR_TSP,
> >>> +	I3C_HDR_TSL,
> >>> +};
> >>> +
> >>> +/**
> >>> + * struct i3c_hdr_cmd - I3C HDR command
> >>> + * @mode: HDR mode selected for this command
> >>> + * @code: command opcode
> >>> + * @addr: I3C dynamic address
> >>> + * @ndatawords: number of data words (a word is 16bits wide)
> >>> + * @data: input/output buffer
> >>> + */
> >>> +struct i3c_hdr_cmd {
> >>> +	enum i3c_hdr_mode mode;
> >>> +	u8 code;
> >>> +	u8 addr;
> >>> +	int ndatawords;
> >>> +	union {
> >>> +		u16 *in;
> >>> +		const u16 *out;
> >>> +	} data;
> >>> +};  
> Please mention that the @code is what will define if the transfer is read or write.

Well, I think it's pretty clear in the definition you'll find in the
ccc.h file, but I can add a comment here too if you like.

> >>> +
> >>> +/* Private SDR read transfer */
> >>> +#define I3C_PRIV_XFER_READ		BIT(0)
> >>> +/*
> >>> + * Instruct the controller to issue a STOP after a specific transfer instead
> >>> + * of a REPEATED START.
> >>> + */
> >>> +#define I3C_PRIV_XFER_STOP		BIT(1)
> >>> +
> >>> +/**
> >>> + * struct i3c_priv_xfer - I3C SDR private transfer
> >>> + * @addr: I3C dynamic address
> >>> + * @len: transfer length in bytes of the transfer
> >>> + * @flags: combination of I3C_PRIV_XFER_xxx flags
> >>> + * @data: input/output buffer
> >>> + */
> >>> +struct i3c_priv_xfer {
> >>> +	u8 addr;
> >>> +	u16 len;
> >>> +	u32 flags;
> >>> +	struct {
> >>> +		void *in;
> >>> +		const void *out;
> >>> +	} data;
> >>> +};    
> >>  Same as above, i3c_sdr_max_data_rate to change the bus scl.  
> > If I'm understanding the spec correctly, that's not something you want
> > to change on a per-transfer basis. The constraint is on the device
> > itself and should IMO not be part of the i3c_priv_xfer struct.  
> As mention before this is important.
> You can do the same as for struct i3c_hdr_cmd and add a enum i3c_sdr_max_data_rate.
> 
> The @flag only have 2 bits of load, is the rest opened?

If by open you mean that we can add more flags if we need to, then yes.

> >  
> >>  > +
> >>> +/**
> >>> + * enum i3c_dcr - I3C DCR values
> >>> + * @I3C_DCR_GENERIC_DEVICE: generic I3C device
> >>> + */
> >>> +enum i3c_dcr {
> >>> +	I3C_DCR_GENERIC_DEVICE = 0,
> >>> +};
> >>> +
> >>> +#define I3C_PID_MANUF_ID(pid)		(((pid) & GENMASK_ULL(47, 33)) >> 33)
> >>> +#define I3C_PID_RND_LOWER_32BITS(pid)	(!!((pid) & BIT_ULL(32)))
> >>> +#define I3C_PID_RND_VAL(pid)		((pid) & GENMASK_ULL(31, 0))
> >>> +#define I3C_PID_PART_ID(pid)		(((pid) & GENMASK_ULL(31, 16)) >> 16)
> >>> +#define I3C_PID_INSTANCE_ID(pid)	(((pid) & GENMASK_ULL(15, 12)) >> 12)
> >>> +#define I3C_PID_EXTRA_INFO(pid)		((pid) & GENMASK_ULL(11, 0))
> >>> +
> >>> +#define I3C_BCR_DEVICE_ROLE(bcr)	((bcr) & GENMASK(7, 6))
> >>> +#define I3C_BCR_I3C_SLAVE		(0 << 6)
> >>> +#define I3C_BCR_I3C_MASTER		(1 << 6)
> >>> +#define I3C_BCR_HDR_CAP			BIT(5)
> >>> +#define I3C_BCR_BRIDGE			BIT(4)
> >>> +#define I3C_BCR_OFFLINE_CAP		BIT(3)
> >>> +#define I3C_BCR_IBI_PAYLOAD		BIT(2)
> >>> +#define I3C_BCR_IBI_REQ_CAP		BIT(1)
> >>> +#define I3C_BCR_MAX_DATA_SPEED_LIM	BIT(0)
> >>> +
> >>> +/**
> >>> + * struct i3c_device_info - I3C device information
> >>> + * @pid: Provisional ID
> >>> + * @bcr: Bus Characteristic Register
> >>> + * @dcr: Device Characteristic Register
> >>> + * @static_addr: static/I2C address
> >>> + * @dyn_addr: dynamic address
> >>> + * @hdr_cap: supported HDR modes
> >>> + * @max_read_ds: max read speed information
> >>> + * @max_write_ds: max write speed information
> >>> + * @max_ibi_len: max IBI payload length
> >>> + * @max_read_turnaround: max read turn-around time in micro-seconds
> >>> + * @max_read_len: max private SDR read length in bytes
> >>> + * @max_write_len: max private SDR write length in bytes
> >>> + *
> >>> + * These are all basic information that should be advertised by an I3C device.
> >>> + * Some of them are optional depending on the device type and device
> >>> + * capabilities.
> >>> + * For each I3C slave attached to a master with
> >>> + * i3c_master_add_i3c_dev_locked(), the core will send the relevant CCC command
> >>> + * to retrieve these data.
> >>> + */
> >>> +struct i3c_device_info {
> >>> +	u64 pid;
> >>> +	u8 bcr;
> >>> +	u8 dcr;
> >>> +	u8 static_addr;
> >>> +	u8 dyn_addr;
> >>> +	u8 hdr_cap;
> >>> +	u8 max_read_ds;
> >>> +	u8 max_write_ds;
> >>> +	u8 max_ibi_len;
> >>> +	u32 max_read_turnaround;
> >>> +	u16 max_read_len;
> >>> +	u16 max_write_len;
> >>> +};
> >>> +    
> >>  is this information filled with data provided from CCC commands?  
> > Yes, they are.  
> Ok, them the intention is to do this on bus_init(), right?

Not only, it can be after a Hot-Join, or after the user has triggered a
new DAA. Anyway, these information are retrieved anytime you add a
device with i3c_master_add_i3c_dev_locked(), and the core uses CCC
commands to do that.

> >>> +
> >>> +/**
> >>> + * struct i3c_master_controller_ops - I3C master methods
> >>> + * @bus_init: hook responsible for the I3C bus initialization. This
> >>> + *	      initialization should follow the steps described in the I3C
> >>> + *	      specification. This hook is called with the bus lock held in
> >>> + *	      write mode, which means all _locked() helpers can safely be
> >>> + *	      called from there
> >>> + * @bus_cleanup: cleanup everything done in
> >>> + *		 &i3c_master_controller_ops->bus_init(). This function is
> >>> + *		 optional and should only be implemented if
> >>> + *		 &i3c_master_controller_ops->bus_init() attached private data
> >>> + *		 to I3C/I2C devices. This hook is called with the bus lock
> >>> + *		 held in write mode, which means all _locked() helpers can
> >>> + *		 safely be called from there
> >>> + * @supports_ccc_cmd: should return true if the CCC command is supported, false
> >>> + *		      otherwise
> >>> + * @send_ccc_cmd: send a CCC command
> >>> + * @send_hdr_cmds: send one or several HDR commands. If there is more than one
> >>> + *		   command, they should ideally be sent in the same HDR
> >>> + *		   transaction
> >>> + * @priv_xfers: do one or several private I3C SDR transfers
> >>> + * @i2c_xfers: do one or several I2C transfers
> >>> + * @request_ibi: attach an IBI handler to an I3C device. This implies defining
> >>> + *		 an IBI handler and the constraints of the IBI (maximum payload
> >>> + *		 length and number of pre-allocated slots).
> >>> + *		 Some controllers support less IBI-capable devices than regular
> >>> + *		 devices, so this method might return -%EBUSY if there's no
> >>> + *		 more space for an extra IBI registration
> >>> + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI
> >>> + *	      should have been disabled with ->disable_irq() prior to that
> >>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called
> >>> + *		prior to ->enable_ibi(). The controller should first enable
> >>> + *		the IBI on the controller end (for example, unmask the hardware
> >>> + *		IRQ) and then send the ENEC CCC command (with the IBI flag set)
> >>> + *		to the I3C device
> >>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI
> >>> + *		 flag set and then deactivate the hardware IRQ on the
> >>> + *		 controller end
> >>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been
> >>> + *		      processed by its handler. The IBI slot should be put back
> >>> + *		      in the IBI slot pool so that the controller can re-use it
> >>> + *		      for a future IBI
> >>> + *
> >>> + * One of the most important hooks in these ops is
> >>> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of
> >>> + * things that should be done in &i3c_master_controller_ops->bus_init():
> >>> + *
> >>> + * 1) call i3c_master_set_info() with all information describing the master
> >>> + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC
> >>> + *    with i3c_master_rstdaa_locked()
> >>> + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked()
> >>> + * 4) start a DDA procedure by sending the ENTDAA CCC with
> >>> + *    i3c_master_entdaa_locked(), or using the internal DAA logic provided by
> >>> + *    your controller    
> >> You mean SETDASA CCC command?  
> > No, I really mean ENTDAA and DAA. By internal DAA logic I mean that
> > some controllers are probably automating the whole DAA procedure, while
> > others may let the SW control every step.  
> My understanding is that i3c_master_entdaa_locked() will trigger the DAA process
> and DAA can be done by SETDASA, ENTDAA and later after the bus initialization
> with SETNEWDA.

No. Only ENTDAA can trigger a DAA procedure. SETDASA is here to assign
a single dynamic address to a device that already has a static address
but no dynamic address yet, and SETNEWDA is here to modify the dynamic
address of a device that already has one.

> 
> I think the DAA process should be more generic, right now is only made through
> the ENTDAA command with (cmd.ndests = 1).
> I mean, shouldn't this be made by the core? First doing DAA for the devices
> declared and them try do discover the rest of devices on the bus.

Can you detail a bit more? If the only part you're complaining about is
pre-assignment of dynamic addresses with SETDASA when a device is
declared in the DT with a reg and dynamic-address property, then yes, I
think I can provide an helper for that. But this helper would still have
to be called from the master controller driver (from ->bus_init() or
after a Hot-Join).

Now, if the question is, is there a way we can automate things even more
and completely implement DAA from the core? I doubt it, because the way
the core will trigger DAA, expose discovered devices or allow you to
declare manually assigned addresses is likely to be
controller-dependent.
When I designed the framework I took the decision to base my work on the
spec rather than focusing on the I3C master controller I had to support
(Cadence). This is the reason I decided to keep the interface as simple
as possible at the risk of encouraging code-duplication (at first)
rather than coming up with an interface that is designed with a single
controller in mind and having to break things every time a new
controller comes out.

Thank you for you comments, but I'd like to know if some of my design
choices are blocking you to support your controller. What I've seen so
far is a collection of things that might be relevant to fix (though
most of them are subject to interpretation and/or a matter of taste),
but nothing that should really block you.

Can you clarify that, and maybe come back with a list of things that you
think are preventing you from properly supporting the Synopsys
controller?

Thanks,

Boris 

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-26 20:36         ` Boris Brezillon
@ 2018-02-26 20:40           ` Boris Brezillon
  2018-02-26 21:38             ` Boris Brezillon
  2018-02-27 16:03           ` Vitor Soares
  1 sibling, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2018-02-26 20:40 UTC (permalink / raw)
  To: Vitor Soares
  Cc: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

On Mon, 26 Feb 2018 21:36:07 +0100
Boris Brezillon <boris.brezillon@bootlin.com> wrote:

> > >>> +
> > >>> +/**
> > >>> + * struct i3c_master_controller_ops - I3C master methods
> > >>> + * @bus_init: hook responsible for the I3C bus initialization. This
> > >>> + *	      initialization should follow the steps described in the I3C
> > >>> + *	      specification. This hook is called with the bus lock held in
> > >>> + *	      write mode, which means all _locked() helpers can safely be
> > >>> + *	      called from there
> > >>> + * @bus_cleanup: cleanup everything done in
> > >>> + *		 &i3c_master_controller_ops->bus_init(). This function is
> > >>> + *		 optional and should only be implemented if
> > >>> + *		 &i3c_master_controller_ops->bus_init() attached private data
> > >>> + *		 to I3C/I2C devices. This hook is called with the bus lock
> > >>> + *		 held in write mode, which means all _locked() helpers can
> > >>> + *		 safely be called from there
> > >>> + * @supports_ccc_cmd: should return true if the CCC command is supported, false
> > >>> + *		      otherwise
> > >>> + * @send_ccc_cmd: send a CCC command
> > >>> + * @send_hdr_cmds: send one or several HDR commands. If there is more than one
> > >>> + *		   command, they should ideally be sent in the same HDR
> > >>> + *		   transaction
> > >>> + * @priv_xfers: do one or several private I3C SDR transfers
> > >>> + * @i2c_xfers: do one or several I2C transfers
> > >>> + * @request_ibi: attach an IBI handler to an I3C device. This implies defining
> > >>> + *		 an IBI handler and the constraints of the IBI (maximum payload
> > >>> + *		 length and number of pre-allocated slots).
> > >>> + *		 Some controllers support less IBI-capable devices than regular
> > >>> + *		 devices, so this method might return -%EBUSY if there's no
> > >>> + *		 more space for an extra IBI registration
> > >>> + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI
> > >>> + *	      should have been disabled with ->disable_irq() prior to that
> > >>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called
> > >>> + *		prior to ->enable_ibi(). The controller should first enable
> > >>> + *		the IBI on the controller end (for example, unmask the hardware
> > >>> + *		IRQ) and then send the ENEC CCC command (with the IBI flag set)
> > >>> + *		to the I3C device
> > >>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI
> > >>> + *		 flag set and then deactivate the hardware IRQ on the
> > >>> + *		 controller end
> > >>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been
> > >>> + *		      processed by its handler. The IBI slot should be put back
> > >>> + *		      in the IBI slot pool so that the controller can re-use it
> > >>> + *		      for a future IBI
> > >>> + *
> > >>> + * One of the most important hooks in these ops is
> > >>> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of
> > >>> + * things that should be done in &i3c_master_controller_ops->bus_init():
> > >>> + *
> > >>> + * 1) call i3c_master_set_info() with all information describing the master
> > >>> + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC
> > >>> + *    with i3c_master_rstdaa_locked()
> > >>> + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked()
> > >>> + * 4) start a DDA procedure by sending the ENTDAA CCC with
> > >>> + *    i3c_master_entdaa_locked(), or using the internal DAA logic provided by
> > >>> + *    your controller      
> > >> You mean SETDASA CCC command?    
> > > No, I really mean ENTDAA and DAA. By internal DAA logic I mean that
> > > some controllers are probably automating the whole DAA procedure, while
> > > others may let the SW control every step.    
> > My understanding is that i3c_master_entdaa_locked() will trigger the DAA process
> > and DAA can be done by SETDASA, ENTDAA and later after the bus initialization
> > with SETNEWDA.  
> 
> No. Only ENTDAA can trigger a DAA procedure. SETDASA is here to assign
> a single dynamic address to a device that already has a static address
> but no dynamic address yet, and SETNEWDA is here to modify the dynamic
> address of a device that already has one.
> 
> > 
> > I think the DAA process should be more generic, right now is only made through
> > the ENTDAA command with (cmd.ndests = 1).
> > I mean, shouldn't this be made by the core? First doing DAA for the devices
> > declared and them try do discover the rest of devices on the bus.  
> 
> Can you detail a bit more? If the only part you're complaining about is
> pre-assignment of dynamic addresses with SETDASA when a device is
> declared in the DT with a reg and dynamic-address property, then yes, I
> think I can provide an helper for that. But this helper would still have
> to be called from the master controller driver (from ->bus_init() or
> after a Hot-Join).
> 
> Now, if the question is, is there a way we can automate things even more
> and completely implement DAA from the core? I doubt it, because the way
> the core will trigger DAA, expose discovered devices or allow you to
> declare manually assigned addresses is likely to be
> controller-dependent.
> When I designed the framework I took the decision to base my work on the
> spec rather than focusing on the I3C master controller I had to support
> (Cadence). This is the reason I decided to keep the interface as simple
> as possible at the risk of encouraging code-duplication (at first)
> rather than coming up with an interface that is designed with a single
> controller in mind and having to break things every time a new
> controller comes out.
> 
> Thank you for you comments, but I'd like to know if some of my design
> choices are blocking you to support your controller. What I've seen so
> far is a collection of things that might be relevant to fix (though
> most of them are subject to interpretation and/or a matter of taste),
> but nothing that should really block you.

Well, that's not entirely true: I agree that something is missing in
->priv_xfers() to let the controller know about the device limitations,
and this could be a blocking aspect.

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-26 20:40           ` Boris Brezillon
@ 2018-02-26 21:38             ` Boris Brezillon
  0 siblings, 0 replies; 50+ messages in thread
From: Boris Brezillon @ 2018-02-26 21:38 UTC (permalink / raw)
  To: Vitor Soares
  Cc: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

On Mon, 26 Feb 2018 21:40:32 +0100
Boris Brezillon <boris.brezillon@bootlin.com> wrote:

> On Mon, 26 Feb 2018 21:36:07 +0100
> Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> 
> > > >>> +
> > > >>> +/**
> > > >>> + * struct i3c_master_controller_ops - I3C master methods
> > > >>> + * @bus_init: hook responsible for the I3C bus initialization. This
> > > >>> + *	      initialization should follow the steps described in the I3C
> > > >>> + *	      specification. This hook is called with the bus lock held in
> > > >>> + *	      write mode, which means all _locked() helpers can safely be
> > > >>> + *	      called from there
> > > >>> + * @bus_cleanup: cleanup everything done in
> > > >>> + *		 &i3c_master_controller_ops->bus_init(). This function is
> > > >>> + *		 optional and should only be implemented if
> > > >>> + *		 &i3c_master_controller_ops->bus_init() attached private data
> > > >>> + *		 to I3C/I2C devices. This hook is called with the bus lock
> > > >>> + *		 held in write mode, which means all _locked() helpers can
> > > >>> + *		 safely be called from there
> > > >>> + * @supports_ccc_cmd: should return true if the CCC command is supported, false
> > > >>> + *		      otherwise
> > > >>> + * @send_ccc_cmd: send a CCC command
> > > >>> + * @send_hdr_cmds: send one or several HDR commands. If there is more than one
> > > >>> + *		   command, they should ideally be sent in the same HDR
> > > >>> + *		   transaction
> > > >>> + * @priv_xfers: do one or several private I3C SDR transfers
> > > >>> + * @i2c_xfers: do one or several I2C transfers
> > > >>> + * @request_ibi: attach an IBI handler to an I3C device. This implies defining
> > > >>> + *		 an IBI handler and the constraints of the IBI (maximum payload
> > > >>> + *		 length and number of pre-allocated slots).
> > > >>> + *		 Some controllers support less IBI-capable devices than regular
> > > >>> + *		 devices, so this method might return -%EBUSY if there's no
> > > >>> + *		 more space for an extra IBI registration
> > > >>> + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI
> > > >>> + *	      should have been disabled with ->disable_irq() prior to that
> > > >>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called
> > > >>> + *		prior to ->enable_ibi(). The controller should first enable
> > > >>> + *		the IBI on the controller end (for example, unmask the hardware
> > > >>> + *		IRQ) and then send the ENEC CCC command (with the IBI flag set)
> > > >>> + *		to the I3C device
> > > >>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI
> > > >>> + *		 flag set and then deactivate the hardware IRQ on the
> > > >>> + *		 controller end
> > > >>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been
> > > >>> + *		      processed by its handler. The IBI slot should be put back
> > > >>> + *		      in the IBI slot pool so that the controller can re-use it
> > > >>> + *		      for a future IBI
> > > >>> + *
> > > >>> + * One of the most important hooks in these ops is
> > > >>> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of
> > > >>> + * things that should be done in &i3c_master_controller_ops->bus_init():
> > > >>> + *
> > > >>> + * 1) call i3c_master_set_info() with all information describing the master
> > > >>> + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC
> > > >>> + *    with i3c_master_rstdaa_locked()
> > > >>> + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked()
> > > >>> + * 4) start a DDA procedure by sending the ENTDAA CCC with
> > > >>> + *    i3c_master_entdaa_locked(), or using the internal DAA logic provided by
> > > >>> + *    your controller        
> > > >> You mean SETDASA CCC command?      
> > > > No, I really mean ENTDAA and DAA. By internal DAA logic I mean that
> > > > some controllers are probably automating the whole DAA procedure, while
> > > > others may let the SW control every step.      
> > > My understanding is that i3c_master_entdaa_locked() will trigger the DAA process
> > > and DAA can be done by SETDASA, ENTDAA and later after the bus initialization
> > > with SETNEWDA.    
> > 
> > No. Only ENTDAA can trigger a DAA procedure. SETDASA is here to assign
> > a single dynamic address to a device that already has a static address
> > but no dynamic address yet, and SETNEWDA is here to modify the dynamic
> > address of a device that already has one.
> >   
> > > 
> > > I think the DAA process should be more generic, right now is only made through
> > > the ENTDAA command with (cmd.ndests = 1).
> > > I mean, shouldn't this be made by the core? First doing DAA for the devices
> > > declared and them try do discover the rest of devices on the bus.    
> > 
> > Can you detail a bit more? If the only part you're complaining about is
> > pre-assignment of dynamic addresses with SETDASA when a device is
> > declared in the DT with a reg and dynamic-address property, then yes, I
> > think I can provide an helper for that. But this helper would still have
> > to be called from the master controller driver (from ->bus_init() or
> > after a Hot-Join).
> > 
> > Now, if the question is, is there a way we can automate things even more
> > and completely implement DAA from the core? I doubt it, because the way
> > the core will trigger DAA, expose discovered devices or allow you to
> > declare manually assigned addresses is likely to be
> > controller-dependent.
> > When I designed the framework I took the decision to base my work on the
> > spec rather than focusing on the I3C master controller I had to support
> > (Cadence). This is the reason I decided to keep the interface as simple
> > as possible at the risk of encouraging code-duplication (at first)
> > rather than coming up with an interface that is designed with a single
> > controller in mind and having to break things every time a new
> > controller comes out.
> > 
> > Thank you for you comments, but I'd like to know if some of my design
> > choices are blocking you to support your controller. What I've seen so
> > far is a collection of things that might be relevant to fix (though
> > most of them are subject to interpretation and/or a matter of taste),
> > but nothing that should really block you.  
> 
> Well, that's not entirely true: I agree that something is missing in
> ->priv_xfers() to let the controller know about the device limitations,  
> and this could be a blocking aspect.
> 

And I2C functionalities might differ between I3C master controllers, so
that's also something we should transfer to the I3C master driver
instead of imposing it in the core.

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-26 20:36         ` Boris Brezillon
  2018-02-26 20:40           ` Boris Brezillon
@ 2018-02-27 16:03           ` Vitor Soares
  2018-02-27 16:43             ` Przemyslaw Sroka
  2018-02-27 19:57             ` Boris Brezillon
  1 sibling, 2 replies; 50+ messages in thread
From: Vitor Soares @ 2018-02-27 16:03 UTC (permalink / raw)
  To: Boris Brezillon, Vitor Soares
  Cc: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

Hi Boris


Às 8:36 PM de 2/26/2018, Boris Brezillon escreveu:
> Hi Vitor,
>
> On Mon, 26 Feb 2018 18:58:15 +0000
> Vitor Soares <Vitor.Soares@synopsys.com> wrote:
>
>>>>> +/**
>>>>> + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a
>>>>> + *				specific device
>>>>> + *
>>>>> + * @dev: device with which the transfers should be done
>>>>> + * @xfers: array of transfers
>>>>> + * @nxfers: number of transfers
>>>>> + *
>>>>> + * Initiate one or several private SDR transfers with @dev.
>>>>> + *
>>>>> + * This function can sleep and thus cannot be called in atomic context.
>>>>> + *
>>>>> + * Return: 0 in case of success, a negative error core otherwise.
>>>>> + */
>>>>> +int i3c_device_do_priv_xfers(struct i3c_device *dev,
>>>>> +			     struct i3c_priv_xfer *xfers,
>>>>> +			     int nxfers)
>>>>> +{
>>>>> +	struct i3c_master_controller *master;
>>>>> +	int i, ret;
>>>>> +
>>>>> +	master = i3c_device_get_master(dev);
>>>>> +	if (!master)
>>>>> +		return -EINVAL;
>>>>> +
>>>>> +	i3c_bus_normaluse_lock(master->bus);
>>>>> +	for (i = 0; i < nxfers; i++)
>>>>> +		xfers[i].addr = dev->info.dyn_addr;
>>>>> +
>>>>> +	ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
>>>>> +	i3c_bus_normaluse_unlock(master->bus);
>>>>> +
>>>>> +	return ret;
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);    
>>>>  The controller should know the speed mode for each xfer. The SDR0 mode 
>>>> is used by default but if any device have read or write speed 
>>>> limitations the controller can use SDRx.  
>>> I might be wrong, but that's not my understanding of the spec. A device
>>> can express a speed limitation for SDR priv transfers, but this
>>> limitation applies to all SDR transfers.
>>>
>>> The speed R/W speed limitation is encoded in the device object, so, if
>>> the controller has to configure that on a per-transfer basis, one
>>> solution would be to pass the device to the ->priv_xfers().  
>> The speed R/W limitation is only for private transfers. Also the device can have
>> a limitation to write and not for read data.
>> This information is obtained with the command GETMXDS which returns the Maximum
>> Sustained Data Rate for non-CCC messages.
> And that's exactly what I expose in i3c_device_info, which is embedded
> in i3c_device, so you should have all the information you need to
> determine the speed in the controller driver if ->priv_xfer() is passed
> the device attached to those transfers. Would that be okay if we pass an
> i3c_device object to ->priv_xfers()?

If you pass the i3c_device to ->priv_xfer(), then you won't need the address too.

Maybe someone else can give other point of view.

>>>  
>>>> This could be also applied to i2c transfers.  
>>> Not really. The max SCL frequency is something that applies to the
>>> whole bus, because all I2C devices have to decode the address when
>>> messages are sent on the bus to determine if they should ignore or
>>> process the message.
>>>  
>>>>> +#endif /* I3C_INTERNAL_H */
>>>>> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
>>>>> new file mode 100644
>>>>> index 000000000000..1c85abac08d5
>>>>> --- /dev/null
>>>>> +++ b/drivers/i3c/master.c
>>>>> @@ -0,0 +1,1433 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>> +/*
>>>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
>>>>> + *
>>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
>>>>> + */
>>>>> +
>>>>> +#include <linux/slab.h>
>>>>> +
>>>>> +#include "internals.h"
>>>>> +
>>>>> +/**
>>>>> + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
>>>>> + *				procedure
>>>>> + * @master: master used to send frames on the bus
>>>>> + *
>>>>> + * Send a ENTDAA CCC command to start a DAA procedure.
>>>>> + *
>>>>> + * Note that this function only sends the ENTDAA CCC command, all the logic
>>>>> + * behind dynamic address assignment has to be handled in the I3C master
>>>>> + * driver.
>>>>> + *
>>>>> + * This function must be called with the bus lock held in write mode.
>>>>> + *
>>>>> + * Return: 0 in case of success, a negative error code otherwise.
>>>>> + */
>>>>> +int i3c_master_entdaa_locked(struct i3c_master_controller *master)
>>>>> +{
>>>>> +	struct i3c_ccc_cmd_dest dest = { };
>>>>> +	struct i3c_ccc_cmd cmd = { };
>>>>> +	int ret;
>>>>> +
>>>>> +	dest.addr = I3C_BROADCAST_ADDR;
>>>>> +	cmd.dests = &dest;
>>>>> +	cmd.ndests = 1;
>>>>> +	cmd.rnw = false;
>>>>> +	cmd.id = I3C_CCC_ENTDAA;
>>>>> +
>>>>> +	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
>>>>> +	if (ret)
>>>>> +		return ret;
>>>>> +
>>>>> +	return 0;
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked);    
>>>>  can you explain the process?  
>>> Not sure what you mean. The ENTDAA is just a CCC command that is used
>>> to trigger a DAA procedure. What the master controller does when it
>>> sends such a command is likely to be controller dependent, and it might
>>> even be possible that you don't need to call this function in your
>>> controller driver to trigger a DAA. If you want more details about the
>>> bus initialization steps and how the ENTDAA CCC command fits into it I
>>> recommend reading section "5.1.4 Bus Initialization and Dynamic Address
>>> Assignment Mode"
>>>  
>>>> the command is only execute once, what if 
>>>> there is more devices on the bus?  
>>> Again, I'm not sure what you mean. The ENTDAA command is sent every
>>> time a controller wants to discover new devices on the bus, that can be
>>> when initializing the bus, after a Hot Join event or simply triggered
>>> by the user (the last case is not supported yet though).
>>>
>>> Now, if you're interested in what happens after an ENTDAA CCC is sent,
>>> the controller will keep sending RepeatedStart until there's no more
>>> devices acking the request. You can have a look at "B.3 Error Types in
>>> Dynamic Address Arbitration" for more details.  
>> My understanding is this command shall be executed once, this mean that only one
>> slave will assign the dynamic address (cmd.ndests = 1) and not trigger the whole
>> process of DAA.
> No, that's not what happens. The master controller is supposed to
> continue until no one replies with an Ack on the bus, and by continue I
> don't mean resend an ENTDAA, but issue a RepeatedStart followed by the
> broadcast address (0x7e).

I am sorry, you have point here. I misunderstood that the cmd.ndests = 1 is for
broadcast commands.

>> Either important is the SETDASA for declared I3C devices. So the DAA process
>> should start by send an SETDASA and them ENTDAA CCC command.
> My understanding was that SETDASA was not mandatory, and was only useful
> when one wants to assign a specific dynamic address to a slave that has
> a static address (which is again not mandatory).
> I've tested it, and even devices with a static address participate to
> the DAA procedure if they've not been assigned a dynamic address yet,
> so I don't see the need for this SETDASA step if you don't need to
> assign a particular dynamic address to the device.
>
> Could you tell me why you think SETDASA is required?

Yes, you are right... But in my opinion it is required as it does part of DAA
process.

>>>>> +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap)
>>>>> +{
>>>>> +	return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR;
>>>>> +}    
>>>>  Is I2C_FUNC_10BIT_ADDR allowed ?  
>>> According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes (at
>>> least that my understanding). And the Cadence controller supports it.  
>> The table say the oposite. The I2C extended address feature is not used on I3C
>> bus, thus this feature shall be disable.
> Actually, I was wrong when initially mentioning this table: it's about
> I2C features supported on I3C slaves, so not really what we're looking
> for. Here, we're wondering if I2C-only devices can have 10-bit
> addresses. The Cadence controller supports that, so there's probably
> nothing preventing use of 10-bit addresses for I2C transfers, but maybe
> not all I3C master controllers support that, so we should probably
> let the I3C master driver implement this method.

The spec says that is "not used" so it will not interface with I3C bus.

>> BTW it is optional on I2C devices.
> You mean I2C controllers? When an I2C device has a 10bit address, the
> controller has to support this mode to communicate with the device, at
> least that's my understanding. But we're digressing a bit. The
> question is not whether I2C devices can optionally use a 10 bit
> address, but whether I3C master controller can support this mode for
> I2C transfers to I2C-only devices.

By the i2c spec the 10-bit address is optional, however the 7-bit address is
mandatory.

>>>  
>>>>  > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
>>>>> new file mode 100644
>>>>> index 000000000000..e69de29bb2d1
>>>>> diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
>>>>> new file mode 100644
>>>>> index 000000000000..e69de29bb2d1
>>>>> diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h
>>>>> new file mode 100644
>>>>> index 000000000000..ff3e1a3e2c4c
>>>>> --- /dev/null
>>>>> +++ b/include/linux/i3c/ccc.h
>>>>> @@ -0,0 +1,380 @@
>>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>>> +/*
>>>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
>>>>> + *
>>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
>>>>> + */
>>>>> +
>>>>> +
>>>>> +/**
>>>>> + * enum i3c_ccc_test_mode - enum listing all available test modes
>>>>> + *
>>>>> + * @I3C_CCC_EXIT_TEST_MODE: exit test mode
>>>>> + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode
>>>>> + */
>>>>> +enum i3c_ccc_test_mode {
>>>>> +	I3C_CCC_EXIT_TEST_MODE,
>>>>> +	I3C_CCC_VENDOR_TEST_MODE,
>>>>> +};
>>>>> +
>>>>> +/**
>>>>> + * struct i3c_ccc_enttm - payload passed to ENTTM CCC
>>>>> + *
>>>>> + * @mode: one of the &enum i3c_ccc_test_mode modes
>>>>> + *
>>>>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
>>>>> + * specific test mode.
>>>>> + */
>>>>> +struct i3c_ccc_enttm {
>>>>> +	u8 mode;
>>>>> +} __packed;
>>>>> +
>>>>> +/**
>>>>> + * struct i3c_ccc_setda - payload passed to ENTTM CCC
>>>>> + *
>>>>> + * @mode: one of the &enum i3c_ccc_test_mode modes
>>>>> + *
>>>>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
>>>>> + * specific test mode.
>>>>> + */
>>>>> +struct i3c_ccc_setda {
>>>>> +	u8 addr;
>>>>> +} __packed;    
>>>>  what do you mean with struct? Maybe setdasa? if so, what is the addr?  
>> Do you have the function to use this structure? Because one command use the
>> static address and the other use the dynamic address.
>>
>>>>  
>>>>  > +/**
>>>>> + * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers
>>>>> + */
>>>>> +enum i3c_sdr_max_data_rate {
>>>>> +	I3C_SDR_DR_FSCL_MAX,
>>>>> +	I3C_SDR_DR_FSCL_8MHZ,
>>>>> +	I3C_SDR_DR_FSCL_6MHZ,
>>>>> +	I3C_SDR_DR_FSCL_4MHZ,
>>>>> +	I3C_SDR_DR_FSCL_2MHZ,
>>>>> +};    
>>>> Can you change the names to:
>>>>
>>>> I3C_SDR0_FSCL_MAX,
>>>> I3C_SDR1_FSCL_8MHZ,
>>>> I3C_SDR2_FSCL_6MHZ,
>>>> I3C_SDR3_FSCL_4MHZ,
>>>> I3C_SDR4_FSCL_2MHZ,
>>>>
>>>> thus the data rate isn't repeated.  
>>> What's the problem with the name I use? Moreover, I see no mention to
>>> the SDR0,1,2,3,4 modes in the public spec.  
>> When you get the GETMXDS information, the maxWr and maxRd came from 0 to 4, so
>> in my opinion I think in this way is easier to have a relationship.
> It's an emum, and there's no mention of the SDRX modes you're using
> here in the I3C spec. I guess it's named this way in your I3C
> controller datasheet. I personally don't see a good reason to add SDRX
> in the name, but if you insist...

The idea is to say that it is SDR mode and the value that GETMXDS command
return. It is what makes sense to me.

>>>>> +
>>>>> +#endif /* I3C_CCC_H */
>>>>> diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h
>>>>> new file mode 100644
>>>>> index 000000000000..83958d3a02e2
>>>>> --- /dev/null
>>>>> +++ b/include/linux/i3c/device.h
>>>>> @@ -0,0 +1,321 @@
>>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>>> +/*
>>>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
>>>>> + *
>>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
>>>>> + */
>>>>> +
>>>>> +#ifndef I3C_DEV_H
>>>>> +#define I3C_DEV_H
>>>>> +
>>>>> +#include <linux/device.h>
>>>>> +#include <linux/i2c.h>
>>>>> +#include <linux/mod_devicetable.h>
>>>>> +#include <linux/module.h>
>>>>> +
>>>>> +/**
>>>>> + * enum i3c_hdr_mode - HDR mode ids
>>>>> + * @I3C_HDR_DDR: DDR mode
>>>>> + * @I3C_HDR_TSP: TSP mode
>>>>> + * @I3C_HDR_TSL: TSL mode
>>>>> + */
>>>>> +enum i3c_hdr_mode {
>>>>> +	I3C_HDR_DDR,
>>>>> +	I3C_HDR_TSP,
>>>>> +	I3C_HDR_TSL,
>>>>> +};
>>>>> +
>>>>> +/**
>>>>> + * struct i3c_hdr_cmd - I3C HDR command
>>>>> + * @mode: HDR mode selected for this command
>>>>> + * @code: command opcode
>>>>> + * @addr: I3C dynamic address
>>>>> + * @ndatawords: number of data words (a word is 16bits wide)
>>>>> + * @data: input/output buffer
>>>>> + */
>>>>> +struct i3c_hdr_cmd {
>>>>> +	enum i3c_hdr_mode mode;
>>>>> +	u8 code;
>>>>> +	u8 addr;
>>>>> +	int ndatawords;
>>>>> +	union {
>>>>> +		u16 *in;
>>>>> +		const u16 *out;
>>>>> +	} data;
>>>>> +};  
>> Please mention that the @code is what will define if the transfer is read or write.
> Well, I think it's pretty clear in the definition you'll find in the
> ccc.h file, but I can add a comment here too if you like.

I don't find it in ccc.h file. Anyway is not good to put this definition there
because is not related.

>>>>> +
>>>>> +/* Private SDR read transfer */
>>>>> +#define I3C_PRIV_XFER_READ		BIT(0)
>>>>> +/*
>>>>> + * Instruct the controller to issue a STOP after a specific transfer instead
>>>>> + * of a REPEATED START.
>>>>> + */
>>>>> +#define I3C_PRIV_XFER_STOP		BIT(1)
>>>>> +
>>>>> +/**
>>>>> + * struct i3c_priv_xfer - I3C SDR private transfer
>>>>> + * @addr: I3C dynamic address
>>>>> + * @len: transfer length in bytes of the transfer
>>>>> + * @flags: combination of I3C_PRIV_XFER_xxx flags
>>>>> + * @data: input/output buffer
>>>>> + */
>>>>> +struct i3c_priv_xfer {
>>>>> +	u8 addr;
>>>>> +	u16 len;
>>>>> +	u32 flags;
>>>>> +	struct {
>>>>> +		void *in;
>>>>> +		const void *out;
>>>>> +	} data;
>>>>> +};    
>>>>  Same as above, i3c_sdr_max_data_rate to change the bus scl.  
>>> If I'm understanding the spec correctly, that's not something you want
>>> to change on a per-transfer basis. The constraint is on the device
>>> itself and should IMO not be part of the i3c_priv_xfer struct.  
>> As mention before this is important.
>> You can do the same as for struct i3c_hdr_cmd and add a enum i3c_sdr_max_data_rate.
>>
>> The @flag only have 2 bits of load, is the rest opened?
> If by open you mean that we can add more flags if we need to, then yes.
>
>>>  
>>>>  > +
>>>>> +/**
>>>>> + * enum i3c_dcr - I3C DCR values
>>>>> + * @I3C_DCR_GENERIC_DEVICE: generic I3C device
>>>>> + */
>>>>> +enum i3c_dcr {
>>>>> +	I3C_DCR_GENERIC_DEVICE = 0,
>>>>> +};
>>>>> +
>>>>> +#define I3C_PID_MANUF_ID(pid)		(((pid) & GENMASK_ULL(47, 33)) >> 33)
>>>>> +#define I3C_PID_RND_LOWER_32BITS(pid)	(!!((pid) & BIT_ULL(32)))
>>>>> +#define I3C_PID_RND_VAL(pid)		((pid) & GENMASK_ULL(31, 0))
>>>>> +#define I3C_PID_PART_ID(pid)		(((pid) & GENMASK_ULL(31, 16)) >> 16)
>>>>> +#define I3C_PID_INSTANCE_ID(pid)	(((pid) & GENMASK_ULL(15, 12)) >> 12)
>>>>> +#define I3C_PID_EXTRA_INFO(pid)		((pid) & GENMASK_ULL(11, 0))
>>>>> +
>>>>> +#define I3C_BCR_DEVICE_ROLE(bcr)	((bcr) & GENMASK(7, 6))
>>>>> +#define I3C_BCR_I3C_SLAVE		(0 << 6)
>>>>> +#define I3C_BCR_I3C_MASTER		(1 << 6)
>>>>> +#define I3C_BCR_HDR_CAP			BIT(5)
>>>>> +#define I3C_BCR_BRIDGE			BIT(4)
>>>>> +#define I3C_BCR_OFFLINE_CAP		BIT(3)
>>>>> +#define I3C_BCR_IBI_PAYLOAD		BIT(2)
>>>>> +#define I3C_BCR_IBI_REQ_CAP		BIT(1)
>>>>> +#define I3C_BCR_MAX_DATA_SPEED_LIM	BIT(0)
>>>>> +
>>>>> +/**
>>>>> + * struct i3c_device_info - I3C device information
>>>>> + * @pid: Provisional ID
>>>>> + * @bcr: Bus Characteristic Register
>>>>> + * @dcr: Device Characteristic Register
>>>>> + * @static_addr: static/I2C address
>>>>> + * @dyn_addr: dynamic address
>>>>> + * @hdr_cap: supported HDR modes
>>>>> + * @max_read_ds: max read speed information
>>>>> + * @max_write_ds: max write speed information
>>>>> + * @max_ibi_len: max IBI payload length
>>>>> + * @max_read_turnaround: max read turn-around time in micro-seconds
>>>>> + * @max_read_len: max private SDR read length in bytes
>>>>> + * @max_write_len: max private SDR write length in bytes
>>>>> + *
>>>>> + * These are all basic information that should be advertised by an I3C device.
>>>>> + * Some of them are optional depending on the device type and device
>>>>> + * capabilities.
>>>>> + * For each I3C slave attached to a master with
>>>>> + * i3c_master_add_i3c_dev_locked(), the core will send the relevant CCC command
>>>>> + * to retrieve these data.
>>>>> + */
>>>>> +struct i3c_device_info {
>>>>> +	u64 pid;
>>>>> +	u8 bcr;
>>>>> +	u8 dcr;
>>>>> +	u8 static_addr;
>>>>> +	u8 dyn_addr;
>>>>> +	u8 hdr_cap;
>>>>> +	u8 max_read_ds;
>>>>> +	u8 max_write_ds;
>>>>> +	u8 max_ibi_len;
>>>>> +	u32 max_read_turnaround;
>>>>> +	u16 max_read_len;
>>>>> +	u16 max_write_len;
>>>>> +};
>>>>> +    
>>>>  is this information filled with data provided from CCC commands?  
>>> Yes, they are.  
>> Ok, them the intention is to do this on bus_init(), right?
> Not only, it can be after a Hot-Join, or after the user has triggered a
> new DAA. Anyway, these information are retrieved anytime you add a
> device with i3c_master_add_i3c_dev_locked(), and the core uses CCC
> commands to do that.
>
>>>>> +
>>>>> +/**
>>>>> + * struct i3c_master_controller_ops - I3C master methods
>>>>> + * @bus_init: hook responsible for the I3C bus initialization. This
>>>>> + *	      initialization should follow the steps described in the I3C
>>>>> + *	      specification. This hook is called with the bus lock held in
>>>>> + *	      write mode, which means all _locked() helpers can safely be
>>>>> + *	      called from there
>>>>> + * @bus_cleanup: cleanup everything done in
>>>>> + *		 &i3c_master_controller_ops->bus_init(). This function is
>>>>> + *		 optional and should only be implemented if
>>>>> + *		 &i3c_master_controller_ops->bus_init() attached private data
>>>>> + *		 to I3C/I2C devices. This hook is called with the bus lock
>>>>> + *		 held in write mode, which means all _locked() helpers can
>>>>> + *		 safely be called from there
>>>>> + * @supports_ccc_cmd: should return true if the CCC command is supported, false
>>>>> + *		      otherwise
>>>>> + * @send_ccc_cmd: send a CCC command
>>>>> + * @send_hdr_cmds: send one or several HDR commands. If there is more than one
>>>>> + *		   command, they should ideally be sent in the same HDR
>>>>> + *		   transaction
>>>>> + * @priv_xfers: do one or several private I3C SDR transfers
>>>>> + * @i2c_xfers: do one or several I2C transfers
>>>>> + * @request_ibi: attach an IBI handler to an I3C device. This implies defining
>>>>> + *		 an IBI handler and the constraints of the IBI (maximum payload
>>>>> + *		 length and number of pre-allocated slots).
>>>>> + *		 Some controllers support less IBI-capable devices than regular
>>>>> + *		 devices, so this method might return -%EBUSY if there's no
>>>>> + *		 more space for an extra IBI registration
>>>>> + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI
>>>>> + *	      should have been disabled with ->disable_irq() prior to that
>>>>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called
>>>>> + *		prior to ->enable_ibi(). The controller should first enable
>>>>> + *		the IBI on the controller end (for example, unmask the hardware
>>>>> + *		IRQ) and then send the ENEC CCC command (with the IBI flag set)
>>>>> + *		to the I3C device
>>>>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI
>>>>> + *		 flag set and then deactivate the hardware IRQ on the
>>>>> + *		 controller end
>>>>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been
>>>>> + *		      processed by its handler. The IBI slot should be put back
>>>>> + *		      in the IBI slot pool so that the controller can re-use it
>>>>> + *		      for a future IBI
>>>>> + *
>>>>> + * One of the most important hooks in these ops is
>>>>> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of
>>>>> + * things that should be done in &i3c_master_controller_ops->bus_init():
>>>>> + *
>>>>> + * 1) call i3c_master_set_info() with all information describing the master
>>>>> + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC
>>>>> + *    with i3c_master_rstdaa_locked()
>>>>> + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked()
>>>>> + * 4) start a DDA procedure by sending the ENTDAA CCC with
>>>>> + *    i3c_master_entdaa_locked(), or using the internal DAA logic provided by
>>>>> + *    your controller    
>>>> You mean SETDASA CCC command?  
>>> No, I really mean ENTDAA and DAA. By internal DAA logic I mean that
>>> some controllers are probably automating the whole DAA procedure, while
>>> others may let the SW control every step.  
>> My understanding is that i3c_master_entdaa_locked() will trigger the DAA process
>> and DAA can be done by SETDASA, ENTDAA and later after the bus initialization
>> with SETNEWDA.
> No. Only ENTDAA can trigger a DAA procedure. SETDASA is here to assign
> a single dynamic address to a device that already has a static address
> but no dynamic address yet, and SETNEWDA is here to modify the dynamic
> address of a device that already has one.

>> I think the DAA process should be more generic, right now is only made through
>> the ENTDAA command with (cmd.ndests = 1).
>> I mean, shouldn't this be made by the core? First doing DAA for the devices
>> declared and them try do discover the rest of devices on the bus.
> Can you detail a bit more? If the only part you're complaining about is
> pre-assignment of dynamic addresses with SETDASA when a device is
> declared in the DT with a reg and dynamic-address property, then yes, I
> think I can provide an helper for that. But this helper would still have
> to be called from the master controller driver (from ->bus_init() or
> after a Hot-Join).
>
> Now, if the question is, is there a way we can automate things even more
> and completely implement DAA from the core? I doubt it, because the way
> the core will trigger DAA, expose discovered devices or allow you to
> declare manually assigned addresses is likely to be
> controller-dependent.

Please refer to figure 90 of public specification. As you can see the DAA
process should start with SETDASA command.

With the current flow of this patch the DAA process is limited to ENTDAA command
only.

> When I designed the framework I took the decision to base my work on the
> spec rather than focusing on the I3C master controller I had to support
> (Cadence). This is the reason I decided to keep the interface as simple
> as possible at the risk of encouraging code-duplication (at first)
> rather than coming up with an interface that is designed with a single
> controller in mind and having to break things every time a new
> controller comes out.
>
> Thank you for you comments, but I'd like to know if some of my design
> choices are blocking you to support your controller. What I've seen so
> far is a collection of things that might be relevant to fix (though
> most of them are subject to interpretation and/or a matter of taste),
> but nothing that should really block you.
>
> Can you clarify that, and maybe come back with a list of things that you
> think are preventing you from properly supporting the Synopsys
> controller?
>
> Thanks,
>
> Boris 

As you can check from my  comments my concerns are about the i3c specification
without the controller in mind.

Best regards,
Vitor Soares

^ permalink raw reply	[flat|nested] 50+ messages in thread

* RE: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-27 16:03           ` Vitor Soares
@ 2018-02-27 16:43             ` Przemyslaw Sroka
  2018-02-27 17:06               ` Przemyslaw Sroka
  2018-02-27 20:13               ` Boris Brezillon
  2018-02-27 19:57             ` Boris Brezillon
  1 sibling, 2 replies; 50+ messages in thread
From: Przemyslaw Sroka @ 2018-02-27 16:43 UTC (permalink / raw)
  To: Vitor Soares, Boris Brezillon
  Cc: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann, Arkadiusz Golec,
	Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
	Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni,
	Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

Hi Boris and Vitor

Find below my comment on DAA procedure.

> -----Original Message-----
> From: Vitor Soares [mailto:Vitor.Soares@synopsys.com]
> Sent: Tuesday, February 27, 2018 5:04 PM
> To: Boris Brezillon <boris.brezillon@bootlin.com>; Vitor Soares
> <Vitor.Soares@synopsys.com>
> Cc: Boris Brezillon <boris.brezillon@free-electrons.com>; Wolfram Sang
> <wsa@the-dreams.de>; linux-i2c@vger.kernel.org; Jonathan Corbet
> <corbet@lwn.net>; linux-doc@vger.kernel.org; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Arnd Bergmann <arnd@arndb.de>;
> Przemyslaw Sroka <psroka@cadence.com>; Arkadiusz Golec
> <agolec@cadence.com>; Alan Douglas <adouglas@cadence.com>; Bartosz
> Folta <bfolta@cadence.com>; Damian Kos <dkos@cadence.com>; Alicja
> Jurasik-Urbaniak <alicja@cadence.com>; Cyprian Wronka
> <cwronka@cadence.com>; Suresh Punnoose <sureshp@cadence.com>;
> Thomas Petazzoni <thomas.petazzoni@free-electrons.com>; Nishanth
> Menon <nm@ti.com>; Rob Herring <robh+dt@kernel.org>; Pawel Moll
> <pawel.moll@arm.com>; Mark Rutland <mark.rutland@arm.com>; Ian
> Campbell <ijc+devicetree@hellion.org.uk>; Kumar Gala
> <galak@codeaurora.org>; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; Geert Uytterhoeven <geert@linux-m68k.org>; Linus
> Walleij <linus.walleij@linaro.org>
> Subject: Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
> 
> EXTERNAL MAIL
> 
> 
> Hi Boris
> 
> 
> Às 8:36 PM de 2/26/2018, Boris Brezillon escreveu:
> > Hi Vitor,
> >
> > On Mon, 26 Feb 2018 18:58:15 +0000
> > Vitor Soares <Vitor.Soares@synopsys.com> wrote:
> >
> >>>>> +/**
> >>>>> + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed
> to a
> >>>>> + *				specific device
> >>>>> + *
> >>>>> + * @dev: device with which the transfers should be done
> >>>>> + * @xfers: array of transfers
> >>>>> + * @nxfers: number of transfers
> >>>>> + *
> >>>>> + * Initiate one or several private SDR transfers with @dev.
> >>>>> + *
> >>>>> + * This function can sleep and thus cannot be called in atomic
> context.
> >>>>> + *
> >>>>> + * Return: 0 in case of success, a negative error core otherwise.
> >>>>> + */
> >>>>> +int i3c_device_do_priv_xfers(struct i3c_device *dev,
> >>>>> +			     struct i3c_priv_xfer *xfers,
> >>>>> +			     int nxfers)
> >>>>> +{
> >>>>> +	struct i3c_master_controller *master;
> >>>>> +	int i, ret;
> >>>>> +
> >>>>> +	master = i3c_device_get_master(dev);
> >>>>> +	if (!master)
> >>>>> +		return -EINVAL;
> >>>>> +
> >>>>> +	i3c_bus_normaluse_lock(master->bus);
> >>>>> +	for (i = 0; i < nxfers; i++)
> >>>>> +		xfers[i].addr = dev->info.dyn_addr;
> >>>>> +
> >>>>> +	ret = i3c_master_do_priv_xfers_locked(master, xfers,
> nxfers);
> >>>>> +	i3c_bus_normaluse_unlock(master->bus);
> >>>>> +
> >>>>> +	return ret;
> >>>>> +}
> >>>>> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);
> >>>>  The controller should know the speed mode for each xfer. The SDR0
> >>>> mode is used by default but if any device have read or write speed
> >>>> limitations the controller can use SDRx.
> >>> I might be wrong, but that's not my understanding of the spec. A
> >>> device can express a speed limitation for SDR priv transfers, but
> >>> this limitation applies to all SDR transfers.
> >>>
> >>> The speed R/W speed limitation is encoded in the device object, so,
> >>> if the controller has to configure that on a per-transfer basis, one
> >>> solution would be to pass the device to the ->priv_xfers().
> >> The speed R/W limitation is only for private transfers. Also the
> >> device can have a limitation to write and not for read data.
> >> This information is obtained with the command GETMXDS which returns
> >> the Maximum Sustained Data Rate for non-CCC messages.
> > And that's exactly what I expose in i3c_device_info, which is embedded
> > in i3c_device, so you should have all the information you need to
> > determine the speed in the controller driver if ->priv_xfer() is
> > passed the device attached to those transfers. Would that be okay if
> > we pass an i3c_device object to ->priv_xfers()?
> 
> If you pass the i3c_device to ->priv_xfer(), then you won't need the address
> too.
> 
> Maybe someone else can give other point of view.
> 
> >>>
> >>>> This could be also applied to i2c transfers.
> >>> Not really. The max SCL frequency is something that applies to the
> >>> whole bus, because all I2C devices have to decode the address when
> >>> messages are sent on the bus to determine if they should ignore or
> >>> process the message.
> >>>
> >>>>> +#endif /* I3C_INTERNAL_H */
> >>>>> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c new file
> >>>>> mode 100644 index 000000000000..1c85abac08d5
> >>>>> --- /dev/null
> >>>>> +++ b/drivers/i3c/master.c
> >>>>> @@ -0,0 +1,1433 @@
> >>>>> +// SPDX-License-Identifier: GPL-2.0
> >>>>> +/*
> >>>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
> >>>>> + *
> >>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> >>>>> + */
> >>>>> +
> >>>>> +#include <linux/slab.h>
> >>>>> +
> >>>>> +#include "internals.h"
> >>>>> +
> >>>>> +/**
> >>>>> + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address
> Assignment)
> >>>>> + *				procedure
> >>>>> + * @master: master used to send frames on the bus
> >>>>> + *
> >>>>> + * Send a ENTDAA CCC command to start a DAA procedure.
> >>>>> + *
> >>>>> + * Note that this function only sends the ENTDAA CCC command, all
> >>>>> +the logic
> >>>>> + * behind dynamic address assignment has to be handled in the I3C
> >>>>> +master
> >>>>> + * driver.
> >>>>> + *
> >>>>> + * This function must be called with the bus lock held in write
> mode.
> >>>>> + *
> >>>>> + * Return: 0 in case of success, a negative error code otherwise.
> >>>>> + */
> >>>>> +int i3c_master_entdaa_locked(struct i3c_master_controller
> >>>>> +*master) {
> >>>>> +	struct i3c_ccc_cmd_dest dest = { };
> >>>>> +	struct i3c_ccc_cmd cmd = { };
> >>>>> +	int ret;
> >>>>> +
> >>>>> +	dest.addr = I3C_BROADCAST_ADDR;
> >>>>> +	cmd.dests = &dest;
> >>>>> +	cmd.ndests = 1;
> >>>>> +	cmd.rnw = false;
> >>>>> +	cmd.id = I3C_CCC_ENTDAA;
> >>>>> +
> >>>>> +	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
> >>>>> +	if (ret)
> >>>>> +		return ret;
> >>>>> +
> >>>>> +	return 0;
> >>>>> +}
> >>>>> +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked);
> >>>>  can you explain the process?
> >>> Not sure what you mean. The ENTDAA is just a CCC command that is
> >>> used to trigger a DAA procedure. What the master controller does
> >>> when it sends such a command is likely to be controller dependent,
> >>> and it might even be possible that you don't need to call this
> >>> function in your controller driver to trigger a DAA. If you want
> >>> more details about the bus initialization steps and how the ENTDAA
> >>> CCC command fits into it I recommend reading section "5.1.4 Bus
> >>> Initialization and Dynamic Address Assignment Mode"
> >>>
> >>>> the command is only execute once, what if there is more devices on
> >>>> the bus?
> >>> Again, I'm not sure what you mean. The ENTDAA command is sent
> every
> >>> time a controller wants to discover new devices on the bus, that can
> >>> be when initializing the bus, after a Hot Join event or simply
> >>> triggered by the user (the last case is not supported yet though).
> >>>
> >>> Now, if you're interested in what happens after an ENTDAA CCC is
> >>> sent, the controller will keep sending RepeatedStart until there's
> >>> no more devices acking the request. You can have a look at "B.3
> >>> Error Types in Dynamic Address Arbitration" for more details.
> >> My understanding is this command shall be executed once, this mean
> >> that only one slave will assign the dynamic address (cmd.ndests = 1)
> >> and not trigger the whole process of DAA.
> > No, that's not what happens. The master controller is supposed to
> > continue until no one replies with an Ack on the bus, and by continue
> > I don't mean resend an ENTDAA, but issue a RepeatedStart followed by
> > the broadcast address (0x7e).
> 
> I am sorry, you have point here. I misunderstood that the cmd.ndests = 1 is
> for broadcast commands.
> 
> >> Either important is the SETDASA for declared I3C devices. So the DAA
> >> process should start by send an SETDASA and them ENTDAA CCC
> command.
> > My understanding was that SETDASA was not mandatory, and was only
> > useful when one wants to assign a specific dynamic address to a slave
> > that has a static address (which is again not mandatory).
> > I've tested it, and even devices with a static address participate to
> > the DAA procedure if they've not been assigned a dynamic address yet,
> > so I don't see the need for this SETDASA step if you don't need to
> > assign a particular dynamic address to the device.
> >
> > Could you tell me why you think SETDASA is required?
> 
> Yes, you are right... But in my opinion it is required as it does part of DAA
> process.

SETDASA is simply faster than ENTDAA, but only if there is no need to
collect BCR/DCR/PID of such devices. I think most applications would
like to have them as an status information so  after all ENTDAA can 
be regarded as an generic approach (unless I'm mistaken).

> 
> >>>>> +static u32 i3c_master_i2c_functionalities(struct i2c_adapter
> >>>>> +*adap) {
> >>>>> +	return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C |
> I2C_FUNC_10BIT_ADDR;
> >>>>> +}
> >>>>  Is I2C_FUNC_10BIT_ADDR allowed ?
> >>> According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes (at
> >>> least that my understanding). And the Cadence controller supports it.
> >> The table say the oposite. The I2C extended address feature is not
> >> used on I3C bus, thus this feature shall be disable.
> > Actually, I was wrong when initially mentioning this table: it's about
> > I2C features supported on I3C slaves, so not really what we're looking
> > for. Here, we're wondering if I2C-only devices can have 10-bit
> > addresses. The Cadence controller supports that, so there's probably
> > nothing preventing use of 10-bit addresses for I2C transfers, but
> > maybe not all I3C master controllers support that, so we should
> > probably let the I3C master driver implement this method.
> 
> The spec says that is "not used" so it will not interface with I3C bus.
> 
> >> BTW it is optional on I2C devices.
> > You mean I2C controllers? When an I2C device has a 10bit address, the
> > controller has to support this mode to communicate with the device, at
> > least that's my understanding. But we're digressing a bit. The
> > question is not whether I2C devices can optionally use a 10 bit
> > address, but whether I3C master controller can support this mode for
> > I2C transfers to I2C-only devices.
> 
> By the i2c spec the 10-bit address is optional, however the 7-bit address is
> mandatory.
> 
> >>>
> >>>>  > diff --git a/drivers/i3c/master/Kconfig
> >>>> b/drivers/i3c/master/Kconfig
> >>>>> new file mode 100644
> >>>>> index 000000000000..e69de29bb2d1
> >>>>> diff --git a/drivers/i3c/master/Makefile
> >>>>> b/drivers/i3c/master/Makefile new file mode 100644 index
> >>>>> 000000000000..e69de29bb2d1 diff --git a/include/linux/i3c/ccc.h
> >>>>> b/include/linux/i3c/ccc.h new file mode 100644 index
> >>>>> 000000000000..ff3e1a3e2c4c
> >>>>> --- /dev/null
> >>>>> +++ b/include/linux/i3c/ccc.h
> >>>>> @@ -0,0 +1,380 @@
> >>>>> +/* SPDX-License-Identifier: GPL-2.0 */
> >>>>> +/*
> >>>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
> >>>>> + *
> >>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> >>>>> + */
> >>>>> +
> >>>>> +
> >>>>> +/**
> >>>>> + * enum i3c_ccc_test_mode - enum listing all available test modes
> >>>>> + *
> >>>>> + * @I3C_CCC_EXIT_TEST_MODE: exit test mode
> >>>>> + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode  */
> enum
> >>>>> +i3c_ccc_test_mode {
> >>>>> +	I3C_CCC_EXIT_TEST_MODE,
> >>>>> +	I3C_CCC_VENDOR_TEST_MODE,
> >>>>> +};
> >>>>> +
> >>>>> +/**
> >>>>> + * struct i3c_ccc_enttm - payload passed to ENTTM CCC
> >>>>> + *
> >>>>> + * @mode: one of the &enum i3c_ccc_test_mode modes
> >>>>> + *
> >>>>> + * Information passed to the ENTTM CCC to instruct an I3C device
> >>>>> +to enter a
> >>>>> + * specific test mode.
> >>>>> + */
> >>>>> +struct i3c_ccc_enttm {
> >>>>> +	u8 mode;
> >>>>> +} __packed;
> >>>>> +
> >>>>> +/**
> >>>>> + * struct i3c_ccc_setda - payload passed to ENTTM CCC
> >>>>> + *
> >>>>> + * @mode: one of the &enum i3c_ccc_test_mode modes
> >>>>> + *
> >>>>> + * Information passed to the ENTTM CCC to instruct an I3C device
> >>>>> +to enter a
> >>>>> + * specific test mode.
> >>>>> + */
> >>>>> +struct i3c_ccc_setda {
> >>>>> +	u8 addr;
> >>>>> +} __packed;
> >>>>  what do you mean with struct? Maybe setdasa? if so, what is the
> addr?
> >> Do you have the function to use this structure? Because one command
> >> use the static address and the other use the dynamic address.
> >>
> >>>>
> >>>>  > +/**
> >>>>> + * enum i3c_sdr_max_data_rate - max data rate values for private
> >>>>> +SDR transfers  */ enum i3c_sdr_max_data_rate {
> >>>>> +	I3C_SDR_DR_FSCL_MAX,
> >>>>> +	I3C_SDR_DR_FSCL_8MHZ,
> >>>>> +	I3C_SDR_DR_FSCL_6MHZ,
> >>>>> +	I3C_SDR_DR_FSCL_4MHZ,
> >>>>> +	I3C_SDR_DR_FSCL_2MHZ,
> >>>>> +};
> >>>> Can you change the names to:
> >>>>
> >>>> I3C_SDR0_FSCL_MAX,
> >>>> I3C_SDR1_FSCL_8MHZ,
> >>>> I3C_SDR2_FSCL_6MHZ,
> >>>> I3C_SDR3_FSCL_4MHZ,
> >>>> I3C_SDR4_FSCL_2MHZ,
> >>>>
> >>>> thus the data rate isn't repeated.
> >>> What's the problem with the name I use? Moreover, I see no mention
> >>> to the SDR0,1,2,3,4 modes in the public spec.
> >> When you get the GETMXDS information, the maxWr and maxRd came
> from 0
> >> to 4, so in my opinion I think in this way is easier to have a relationship.
> > It's an emum, and there's no mention of the SDRX modes you're using
> > here in the I3C spec. I guess it's named this way in your I3C
> > controller datasheet. I personally don't see a good reason to add SDRX
> > in the name, but if you insist...
> 
> The idea is to say that it is SDR mode and the value that GETMXDS
> command return. It is what makes sense to me.
> 
> >>>>> +
> >>>>> +#endif /* I3C_CCC_H */
> >>>>> diff --git a/include/linux/i3c/device.h
> >>>>> b/include/linux/i3c/device.h new file mode 100644 index
> >>>>> 000000000000..83958d3a02e2
> >>>>> --- /dev/null
> >>>>> +++ b/include/linux/i3c/device.h
> >>>>> @@ -0,0 +1,321 @@
> >>>>> +/* SPDX-License-Identifier: GPL-2.0 */
> >>>>> +/*
> >>>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
> >>>>> + *
> >>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> >>>>> + */
> >>>>> +
> >>>>> +#ifndef I3C_DEV_H
> >>>>> +#define I3C_DEV_H
> >>>>> +
> >>>>> +#include <linux/device.h>
> >>>>> +#include <linux/i2c.h>
> >>>>> +#include <linux/mod_devicetable.h> #include <linux/module.h>
> >>>>> +
> >>>>> +/**
> >>>>> + * enum i3c_hdr_mode - HDR mode ids
> >>>>> + * @I3C_HDR_DDR: DDR mode
> >>>>> + * @I3C_HDR_TSP: TSP mode
> >>>>> + * @I3C_HDR_TSL: TSL mode
> >>>>> + */
> >>>>> +enum i3c_hdr_mode {
> >>>>> +	I3C_HDR_DDR,
> >>>>> +	I3C_HDR_TSP,
> >>>>> +	I3C_HDR_TSL,
> >>>>> +};
> >>>>> +
> >>>>> +/**
> >>>>> + * struct i3c_hdr_cmd - I3C HDR command
> >>>>> + * @mode: HDR mode selected for this command
> >>>>> + * @code: command opcode
> >>>>> + * @addr: I3C dynamic address
> >>>>> + * @ndatawords: number of data words (a word is 16bits wide)
> >>>>> + * @data: input/output buffer
> >>>>> + */
> >>>>> +struct i3c_hdr_cmd {
> >>>>> +	enum i3c_hdr_mode mode;
> >>>>> +	u8 code;
> >>>>> +	u8 addr;
> >>>>> +	int ndatawords;
> >>>>> +	union {
> >>>>> +		u16 *in;
> >>>>> +		const u16 *out;
> >>>>> +	} data;
> >>>>> +};
> >> Please mention that the @code is what will define if the transfer is read
> or write.
> > Well, I think it's pretty clear in the definition you'll find in the
> > ccc.h file, but I can add a comment here too if you like.
> 
> I don't find it in ccc.h file. Anyway is not good to put this definition there
> because is not related.
> 
> >>>>> +
> >>>>> +/* Private SDR read transfer */
> >>>>> +#define I3C_PRIV_XFER_READ		BIT(0)
> >>>>> +/*
> >>>>> + * Instruct the controller to issue a STOP after a specific
> >>>>> +transfer instead
> >>>>> + * of a REPEATED START.
> >>>>> + */
> >>>>> +#define I3C_PRIV_XFER_STOP		BIT(1)
> >>>>> +
> >>>>> +/**
> >>>>> + * struct i3c_priv_xfer - I3C SDR private transfer
> >>>>> + * @addr: I3C dynamic address
> >>>>> + * @len: transfer length in bytes of the transfer
> >>>>> + * @flags: combination of I3C_PRIV_XFER_xxx flags
> >>>>> + * @data: input/output buffer
> >>>>> + */
> >>>>> +struct i3c_priv_xfer {
> >>>>> +	u8 addr;
> >>>>> +	u16 len;
> >>>>> +	u32 flags;
> >>>>> +	struct {
> >>>>> +		void *in;
> >>>>> +		const void *out;
> >>>>> +	} data;
> >>>>> +};
> >>>>  Same as above, i3c_sdr_max_data_rate to change the bus scl.
> >>> If I'm understanding the spec correctly, that's not something you
> >>> want to change on a per-transfer basis. The constraint is on the
> >>> device itself and should IMO not be part of the i3c_priv_xfer struct.
> >> As mention before this is important.
> >> You can do the same as for struct i3c_hdr_cmd and add a enum
> i3c_sdr_max_data_rate.
> >>
> >> The @flag only have 2 bits of load, is the rest opened?
> > If by open you mean that we can add more flags if we need to, then yes.
> >
> >>>
> >>>>  > +
> >>>>> +/**
> >>>>> + * enum i3c_dcr - I3C DCR values
> >>>>> + * @I3C_DCR_GENERIC_DEVICE: generic I3C device  */ enum i3c_dcr
> {
> >>>>> +	I3C_DCR_GENERIC_DEVICE = 0,
> >>>>> +};
> >>>>> +
> >>>>> +#define I3C_PID_MANUF_ID(pid)		(((pid) &
> GENMASK_ULL(47, 33)) >> 33)
> >>>>> +#define I3C_PID_RND_LOWER_32BITS(pid)	(!!((pid) &
> BIT_ULL(32)))
> >>>>> +#define I3C_PID_RND_VAL(pid)		((pid) & GENMASK_ULL(31,
> 0))
> >>>>> +#define I3C_PID_PART_ID(pid)		(((pid) & GENMASK_ULL(31,
> 16)) >> 16)
> >>>>> +#define I3C_PID_INSTANCE_ID(pid)	(((pid) & GENMASK_ULL(15,
> 12)) >> 12)
> >>>>> +#define I3C_PID_EXTRA_INFO(pid)		((pid) &
> GENMASK_ULL(11, 0))
> >>>>> +
> >>>>> +#define I3C_BCR_DEVICE_ROLE(bcr)	((bcr) & GENMASK(7, 6))
> >>>>> +#define I3C_BCR_I3C_SLAVE		(0 << 6)
> >>>>> +#define I3C_BCR_I3C_MASTER		(1 << 6)
> >>>>> +#define I3C_BCR_HDR_CAP			BIT(5)
> >>>>> +#define I3C_BCR_BRIDGE			BIT(4)
> >>>>> +#define I3C_BCR_OFFLINE_CAP		BIT(3)
> >>>>> +#define I3C_BCR_IBI_PAYLOAD		BIT(2)
> >>>>> +#define I3C_BCR_IBI_REQ_CAP		BIT(1)
> >>>>> +#define I3C_BCR_MAX_DATA_SPEED_LIM	BIT(0)
> >>>>> +
> >>>>> +/**
> >>>>> + * struct i3c_device_info - I3C device information
> >>>>> + * @pid: Provisional ID
> >>>>> + * @bcr: Bus Characteristic Register
> >>>>> + * @dcr: Device Characteristic Register
> >>>>> + * @static_addr: static/I2C address
> >>>>> + * @dyn_addr: dynamic address
> >>>>> + * @hdr_cap: supported HDR modes
> >>>>> + * @max_read_ds: max read speed information
> >>>>> + * @max_write_ds: max write speed information
> >>>>> + * @max_ibi_len: max IBI payload length
> >>>>> + * @max_read_turnaround: max read turn-around time in
> >>>>> +micro-seconds
> >>>>> + * @max_read_len: max private SDR read length in bytes
> >>>>> + * @max_write_len: max private SDR write length in bytes
> >>>>> + *
> >>>>> + * These are all basic information that should be advertised by an
> I3C device.
> >>>>> + * Some of them are optional depending on the device type and
> >>>>> +device
> >>>>> + * capabilities.
> >>>>> + * For each I3C slave attached to a master with
> >>>>> + * i3c_master_add_i3c_dev_locked(), the core will send the
> >>>>> +relevant CCC command
> >>>>> + * to retrieve these data.
> >>>>> + */
> >>>>> +struct i3c_device_info {
> >>>>> +	u64 pid;
> >>>>> +	u8 bcr;
> >>>>> +	u8 dcr;
> >>>>> +	u8 static_addr;
> >>>>> +	u8 dyn_addr;
> >>>>> +	u8 hdr_cap;
> >>>>> +	u8 max_read_ds;
> >>>>> +	u8 max_write_ds;
> >>>>> +	u8 max_ibi_len;
> >>>>> +	u32 max_read_turnaround;
> >>>>> +	u16 max_read_len;
> >>>>> +	u16 max_write_len;
> >>>>> +};
> >>>>> +
> >>>>  is this information filled with data provided from CCC commands?
> >>> Yes, they are.
> >> Ok, them the intention is to do this on bus_init(), right?
> > Not only, it can be after a Hot-Join, or after the user has triggered
> > a new DAA. Anyway, these information are retrieved anytime you add a
> > device with i3c_master_add_i3c_dev_locked(), and the core uses CCC
> > commands to do that.
> >
> >>>>> +
> >>>>> +/**
> >>>>> + * struct i3c_master_controller_ops - I3C master methods
> >>>>> + * @bus_init: hook responsible for the I3C bus initialization. This
> >>>>> + *	      initialization should follow the steps described in the I3C
> >>>>> + *	      specification. This hook is called with the bus lock held
> in
> >>>>> + *	      write mode, which means all _locked() helpers can safely
> be
> >>>>> + *	      called from there
> >>>>> + * @bus_cleanup: cleanup everything done in
> >>>>> + *		 &i3c_master_controller_ops->bus_init(). This
> function is
> >>>>> + *		 optional and should only be implemented if
> >>>>> + *		 &i3c_master_controller_ops->bus_init() attached
> private data
> >>>>> + *		 to I3C/I2C devices. This hook is called with the bus
> lock
> >>>>> + *		 held in write mode, which means all _locked()
> helpers can
> >>>>> + *		 safely be called from there
> >>>>> + * @supports_ccc_cmd: should return true if the CCC command is
> supported, false
> >>>>> + *		      otherwise
> >>>>> + * @send_ccc_cmd: send a CCC command
> >>>>> + * @send_hdr_cmds: send one or several HDR commands. If there is
> more than one
> >>>>> + *		   command, they should ideally be sent in the same
> HDR
> >>>>> + *		   transaction
> >>>>> + * @priv_xfers: do one or several private I3C SDR transfers
> >>>>> + * @i2c_xfers: do one or several I2C transfers
> >>>>> + * @request_ibi: attach an IBI handler to an I3C device. This implies
> defining
> >>>>> + *		 an IBI handler and the constraints of the IBI
> (maximum payload
> >>>>> + *		 length and number of pre-allocated slots).
> >>>>> + *		 Some controllers support less IBI-capable devices
> than regular
> >>>>> + *		 devices, so this method might return -%EBUSY if
> there's no
> >>>>> + *		 more space for an extra IBI registration
> >>>>> + * @free_ibi: free an IBI previously requested with ->request_ibi().
> The IBI
> >>>>> + *	      should have been disabled with ->disable_irq() prior to
> that
> >>>>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been
> called
> >>>>> + *		prior to ->enable_ibi(). The controller should first
> enable
> >>>>> + *		the IBI on the controller end (for example, unmask
> the hardware
> >>>>> + *		IRQ) and then send the ENEC CCC command (with
> the IBI flag set)
> >>>>> + *		to the I3C device
> >>>>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command
> with the IBI
> >>>>> + *		 flag set and then deactivate the hardware IRQ on
> the
> >>>>> + *		 controller end
> >>>>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has
> been
> >>>>> + *		      processed by its handler. The IBI slot should be
> put back
> >>>>> + *		      in the IBI slot pool so that the controller can re-
> use it
> >>>>> + *		      for a future IBI
> >>>>> + *
> >>>>> + * One of the most important hooks in these ops is
> >>>>> + * &i3c_master_controller_ops->bus_init(). Here is a
> >>>>> +non-exhaustive list of
> >>>>> + * things that should be done in &i3c_master_controller_ops-
> >bus_init():
> >>>>> + *
> >>>>> + * 1) call i3c_master_set_info() with all information describing
> >>>>> +the master
> >>>>> + * 2) ask all slaves to drop their dynamic address by sending the
> RSTDAA CCC
> >>>>> + *    with i3c_master_rstdaa_locked()
> >>>>> + * 3) ask all slaves to disable IBIs using
> >>>>> +i3c_master_disec_locked()
> >>>>> + * 4) start a DDA procedure by sending the ENTDAA CCC with
> >>>>> + *    i3c_master_entdaa_locked(), or using the internal DAA logic
> provided by
> >>>>> + *    your controller
> >>>> You mean SETDASA CCC command?
> >>> No, I really mean ENTDAA and DAA. By internal DAA logic I mean that
> >>> some controllers are probably automating the whole DAA procedure,
> >>> while others may let the SW control every step.
> >> My understanding is that i3c_master_entdaa_locked() will trigger the
> >> DAA process and DAA can be done by SETDASA, ENTDAA and later after
> >> the bus initialization with SETNEWDA.
> > No. Only ENTDAA can trigger a DAA procedure. SETDASA is here to assign
> > a single dynamic address to a device that already has a static address
> > but no dynamic address yet, and SETNEWDA is here to modify the
> dynamic
> > address of a device that already has one.
> 
> >> I think the DAA process should be more generic, right now is only
> >> made through the ENTDAA command with (cmd.ndests = 1).
> >> I mean, shouldn't this be made by the core? First doing DAA for the
> >> devices declared and them try do discover the rest of devices on the bus.
> > Can you detail a bit more? If the only part you're complaining about
> > is pre-assignment of dynamic addresses with SETDASA when a device is
> > declared in the DT with a reg and dynamic-address property, then yes,
> > I think I can provide an helper for that. But this helper would still
> > have to be called from the master controller driver (from ->bus_init()
> > or after a Hot-Join).
> >
> > Now, if the question is, is there a way we can automate things even
> > more and completely implement DAA from the core? I doubt it, because
> > the way the core will trigger DAA, expose discovered devices or allow
> > you to declare manually assigned addresses is likely to be
> > controller-dependent.
> 
> Please refer to figure 90 of public specification. As you can see the DAA
> process should start with SETDASA command.
> 
> With the current flow of this patch the DAA process is limited to ENTDAA
> command only.
> 
> > When I designed the framework I took the decision to base my work on
> > the spec rather than focusing on the I3C master controller I had to
> > support (Cadence). This is the reason I decided to keep the interface
> > as simple as possible at the risk of encouraging code-duplication (at
> > first) rather than coming up with an interface that is designed with a
> > single controller in mind and having to break things every time a new
> > controller comes out.
> >
> > Thank you for you comments, but I'd like to know if some of my design
> > choices are blocking you to support your controller. What I've seen so
> > far is a collection of things that might be relevant to fix (though
> > most of them are subject to interpretation and/or a matter of taste),
> > but nothing that should really block you.
> >
> > Can you clarify that, and maybe come back with a list of things that
> > you think are preventing you from properly supporting the Synopsys
> > controller?
> >
> > Thanks,
> >
> > Boris
> 
> As you can check from my  comments my concerns are about the i3c
> specification without the controller in mind.
> 
> Best regards,
> Vitor Soares
> 


^ permalink raw reply	[flat|nested] 50+ messages in thread

* RE: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-27 16:43             ` Przemyslaw Sroka
@ 2018-02-27 17:06               ` Przemyslaw Sroka
  2018-02-27 20:25                 ` Boris Brezillon
  2018-02-27 20:13               ` Boris Brezillon
  1 sibling, 1 reply; 50+ messages in thread
From: Przemyslaw Sroka @ 2018-02-27 17:06 UTC (permalink / raw)
  To: Vitor Soares, Boris Brezillon
  Cc: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann, Arkadiusz Golec,
	Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
	Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni,
	Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

More detailed explanation...

> -----Original Message-----
> From: Przemyslaw Sroka
> Sent: Tuesday, February 27, 2018 5:43 PM
> To: 'Vitor Soares' <Vitor.Soares@synopsys.com>; Boris Brezillon
> <boris.brezillon@bootlin.com>
> Cc: Boris Brezillon <boris.brezillon@free-electrons.com>; Wolfram Sang
> <wsa@the-dreams.de>; linux-i2c@vger.kernel.org; Jonathan Corbet
> <corbet@lwn.net>; linux-doc@vger.kernel.org; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Arnd Bergmann <arnd@arndb.de>;
> Arkadiusz Golec <agolec@cadence.com>; Alan Douglas
> <adouglas@cadence.com>; Bartosz Folta <bfolta@cadence.com>; Damian
> Kos <dkos@cadence.com>; Alicja Jurasik-Urbaniak <alicja@cadence.com>;
> Cyprian Wronka <cwronka@cadence.com>; Suresh Punnoose
> <sureshp@cadence.com>; Thomas Petazzoni <thomas.petazzoni@free-
> electrons.com>; Nishanth Menon <nm@ti.com>; Rob Herring
> <robh+dt@kernel.org>; Pawel Moll <pawel.moll@arm.com>; Mark Rutland
> <mark.rutland@arm.com>; Ian Campbell <ijc+devicetree@hellion.org.uk>;
> Kumar Gala <galak@codeaurora.org>; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; Geert Uytterhoeven <geert@linux-m68k.org>; Linus
> Walleij <linus.walleij@linaro.org>
> Subject: RE: [PATCH v2 2/7] i3c: Add core I3C infrastructure
> 
> Hi Boris and Vitor
> 
> Find below my comment on DAA procedure.
> 
> > -----Original Message-----
> > From: Vitor Soares [mailto:Vitor.Soares@synopsys.com]
> > Sent: Tuesday, February 27, 2018 5:04 PM
> > To: Boris Brezillon <boris.brezillon@bootlin.com>; Vitor Soares
> > <Vitor.Soares@synopsys.com>
> > Cc: Boris Brezillon <boris.brezillon@free-electrons.com>; Wolfram Sang
> > <wsa@the-dreams.de>; linux-i2c@vger.kernel.org; Jonathan Corbet
> > <corbet@lwn.net>; linux-doc@vger.kernel.org; Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org>; Arnd Bergmann <arnd@arndb.de>;
> > Przemyslaw Sroka <psroka@cadence.com>; Arkadiusz Golec
> > <agolec@cadence.com>; Alan Douglas <adouglas@cadence.com>; Bartosz
> > Folta <bfolta@cadence.com>; Damian Kos <dkos@cadence.com>; Alicja
> > Jurasik-Urbaniak <alicja@cadence.com>; Cyprian Wronka
> > <cwronka@cadence.com>; Suresh Punnoose <sureshp@cadence.com>;
> Thomas
> > Petazzoni <thomas.petazzoni@free-electrons.com>; Nishanth Menon
> > <nm@ti.com>; Rob Herring <robh+dt@kernel.org>; Pawel Moll
> > <pawel.moll@arm.com>; Mark Rutland <mark.rutland@arm.com>; Ian
> > Campbell <ijc+devicetree@hellion.org.uk>; Kumar Gala
> > <galak@codeaurora.org>; devicetree@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Geert Uytterhoeven <geert@linux-m68k.org>;
> > Linus Walleij <linus.walleij@linaro.org>
> > Subject: Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
> >
> > EXTERNAL MAIL
> >
> >
> > Hi Boris
> >
> >
> > Às 8:36 PM de 2/26/2018, Boris Brezillon escreveu:
> > > Hi Vitor,
> > >
> > > On Mon, 26 Feb 2018 18:58:15 +0000
> > > Vitor Soares <Vitor.Soares@synopsys.com> wrote:
> > >
> > >>>>> +/**
> > >>>>> + * i3c_device_do_priv_xfers() - do I3C SDR private transfers
> > >>>>> +directed
> > to a
> > >>>>> + *				specific device
> > >>>>> + *
> > >>>>> + * @dev: device with which the transfers should be done
> > >>>>> + * @xfers: array of transfers
> > >>>>> + * @nxfers: number of transfers
> > >>>>> + *
> > >>>>> + * Initiate one or several private SDR transfers with @dev.
> > >>>>> + *
> > >>>>> + * This function can sleep and thus cannot be called in atomic
> > context.
> > >>>>> + *
> > >>>>> + * Return: 0 in case of success, a negative error core otherwise.
> > >>>>> + */
> > >>>>> +int i3c_device_do_priv_xfers(struct i3c_device *dev,
> > >>>>> +			     struct i3c_priv_xfer *xfers,
> > >>>>> +			     int nxfers)
> > >>>>> +{
> > >>>>> +	struct i3c_master_controller *master;
> > >>>>> +	int i, ret;
> > >>>>> +
> > >>>>> +	master = i3c_device_get_master(dev);
> > >>>>> +	if (!master)
> > >>>>> +		return -EINVAL;
> > >>>>> +
> > >>>>> +	i3c_bus_normaluse_lock(master->bus);
> > >>>>> +	for (i = 0; i < nxfers; i++)
> > >>>>> +		xfers[i].addr = dev->info.dyn_addr;
> > >>>>> +
> > >>>>> +	ret = i3c_master_do_priv_xfers_locked(master, xfers,
> > nxfers);
> > >>>>> +	i3c_bus_normaluse_unlock(master->bus);
> > >>>>> +
> > >>>>> +	return ret;
> > >>>>> +}
> > >>>>> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);
> > >>>>  The controller should know the speed mode for each xfer. The
> > >>>> SDR0 mode is used by default but if any device have read or write
> > >>>> speed limitations the controller can use SDRx.
> > >>> I might be wrong, but that's not my understanding of the spec. A
> > >>> device can express a speed limitation for SDR priv transfers, but
> > >>> this limitation applies to all SDR transfers.
> > >>>
> > >>> The speed R/W speed limitation is encoded in the device object,
> > >>> so, if the controller has to configure that on a per-transfer
> > >>> basis, one solution would be to pass the device to the ->priv_xfers().
> > >> The speed R/W limitation is only for private transfers. Also the
> > >> device can have a limitation to write and not for read data.
> > >> This information is obtained with the command GETMXDS which
> returns
> > >> the Maximum Sustained Data Rate for non-CCC messages.
> > > And that's exactly what I expose in i3c_device_info, which is
> > > embedded in i3c_device, so you should have all the information you
> > > need to determine the speed in the controller driver if
> > > ->priv_xfer() is passed the device attached to those transfers.
> > > Would that be okay if we pass an i3c_device object to ->priv_xfers()?
> >
> > If you pass the i3c_device to ->priv_xfer(), then you won't need the
> > address too.
> >
> > Maybe someone else can give other point of view.
> >
> > >>>
> > >>>> This could be also applied to i2c transfers.
> > >>> Not really. The max SCL frequency is something that applies to the
> > >>> whole bus, because all I2C devices have to decode the address when
> > >>> messages are sent on the bus to determine if they should ignore or
> > >>> process the message.
> > >>>
> > >>>>> +#endif /* I3C_INTERNAL_H */
> > >>>>> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c new
> > >>>>> file mode 100644 index 000000000000..1c85abac08d5
> > >>>>> --- /dev/null
> > >>>>> +++ b/drivers/i3c/master.c
> > >>>>> @@ -0,0 +1,1433 @@
> > >>>>> +// SPDX-License-Identifier: GPL-2.0
> > >>>>> +/*
> > >>>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
> > >>>>> + *
> > >>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> > >>>>> + */
> > >>>>> +
> > >>>>> +#include <linux/slab.h>
> > >>>>> +
> > >>>>> +#include "internals.h"
> > >>>>> +
> > >>>>> +/**
> > >>>>> + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address
> > Assignment)
> > >>>>> + *				procedure
> > >>>>> + * @master: master used to send frames on the bus
> > >>>>> + *
> > >>>>> + * Send a ENTDAA CCC command to start a DAA procedure.
> > >>>>> + *
> > >>>>> + * Note that this function only sends the ENTDAA CCC command,
> > >>>>> +all the logic
> > >>>>> + * behind dynamic address assignment has to be handled in the
> > >>>>> +I3C master
> > >>>>> + * driver.
> > >>>>> + *
> > >>>>> + * This function must be called with the bus lock held in write
> > mode.
> > >>>>> + *
> > >>>>> + * Return: 0 in case of success, a negative error code otherwise.
> > >>>>> + */
> > >>>>> +int i3c_master_entdaa_locked(struct i3c_master_controller
> > >>>>> +*master) {
> > >>>>> +	struct i3c_ccc_cmd_dest dest = { };
> > >>>>> +	struct i3c_ccc_cmd cmd = { };
> > >>>>> +	int ret;
> > >>>>> +
> > >>>>> +	dest.addr = I3C_BROADCAST_ADDR;
> > >>>>> +	cmd.dests = &dest;
> > >>>>> +	cmd.ndests = 1;
> > >>>>> +	cmd.rnw = false;
> > >>>>> +	cmd.id = I3C_CCC_ENTDAA;
> > >>>>> +
> > >>>>> +	ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
> > >>>>> +	if (ret)
> > >>>>> +		return ret;
> > >>>>> +
> > >>>>> +	return 0;
> > >>>>> +}
> > >>>>> +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked);
> > >>>>  can you explain the process?
> > >>> Not sure what you mean. The ENTDAA is just a CCC command that is
> > >>> used to trigger a DAA procedure. What the master controller does
> > >>> when it sends such a command is likely to be controller dependent,
> > >>> and it might even be possible that you don't need to call this
> > >>> function in your controller driver to trigger a DAA. If you want
> > >>> more details about the bus initialization steps and how the ENTDAA
> > >>> CCC command fits into it I recommend reading section "5.1.4 Bus
> > >>> Initialization and Dynamic Address Assignment Mode"
> > >>>
> > >>>> the command is only execute once, what if there is more devices
> > >>>> on the bus?
> > >>> Again, I'm not sure what you mean. The ENTDAA command is sent
> > every
> > >>> time a controller wants to discover new devices on the bus, that
> > >>> can be when initializing the bus, after a Hot Join event or simply
> > >>> triggered by the user (the last case is not supported yet though).
> > >>>
> > >>> Now, if you're interested in what happens after an ENTDAA CCC is
> > >>> sent, the controller will keep sending RepeatedStart until there's
> > >>> no more devices acking the request. You can have a look at "B.3
> > >>> Error Types in Dynamic Address Arbitration" for more details.
> > >> My understanding is this command shall be executed once, this mean
> > >> that only one slave will assign the dynamic address (cmd.ndests =
> > >> 1) and not trigger the whole process of DAA.
> > > No, that's not what happens. The master controller is supposed to
> > > continue until no one replies with an Ack on the bus, and by
> > > continue I don't mean resend an ENTDAA, but issue a RepeatedStart
> > > followed by the broadcast address (0x7e).
> >
> > I am sorry, you have point here. I misunderstood that the cmd.ndests =
> > 1 is for broadcast commands.
> >
> > >> Either important is the SETDASA for declared I3C devices. So the
> > >> DAA process should start by send an SETDASA and them ENTDAA CCC
> > command.
> > > My understanding was that SETDASA was not mandatory, and was only
> > > useful when one wants to assign a specific dynamic address to a
> > > slave that has a static address (which is again not mandatory).
> > > I've tested it, and even devices with a static address participate
> > > to the DAA procedure if they've not been assigned a dynamic address
> > > yet, so I don't see the need for this SETDASA step if you don't need
> > > to assign a particular dynamic address to the device.
> > >
> > > Could you tell me why you think SETDASA is required?
> >
> > Yes, you are right... But in my opinion it is required as it does part
> > of DAA process.
> 
> SETDASA is simply faster than ENTDAA, but only if there is no need to
> collect BCR/DCR/PID of such devices. I think most applications would like to
> have them as an status information so  after all ENTDAA can be regarded as
> an generic approach (unless I'm mistaken).

Below are 2 examples on how DAA can be executed:
1st:
A1) SETDASA to devices with SA
B1) DAA to remaining devices
C1) GET BCR/DCR/PID to devices that initially had SA
NOTES: C1 is optional and order of B1 and C1 can be changed 

2nd:
A2) DAA to all devices
NOTES: no need for any follow up steps as all information is collected during DAA

As we can see 2nd approach is more generic and do not see any reason to add special handling for SETDASA unless there is any reasonable reason to do otherwise.

> 
> >
> > >>>>> +static u32 i3c_master_i2c_functionalities(struct i2c_adapter
> > >>>>> +*adap) {
> > >>>>> +	return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C |
> > I2C_FUNC_10BIT_ADDR;
> > >>>>> +}
> > >>>>  Is I2C_FUNC_10BIT_ADDR allowed ?
> > >>> According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes
> > >>> (at least that my understanding). And the Cadence controller
> supports it.
> > >> The table say the oposite. The I2C extended address feature is not
> > >> used on I3C bus, thus this feature shall be disable.
> > > Actually, I was wrong when initially mentioning this table: it's
> > > about I2C features supported on I3C slaves, so not really what we're
> > > looking for. Here, we're wondering if I2C-only devices can have
> > > 10-bit addresses. The Cadence controller supports that, so there's
> > > probably nothing preventing use of 10-bit addresses for I2C
> > > transfers, but maybe not all I3C master controllers support that, so
> > > we should probably let the I3C master driver implement this method.
> >
> > The spec says that is "not used" so it will not interface with I3C bus.
> >
> > >> BTW it is optional on I2C devices.
> > > You mean I2C controllers? When an I2C device has a 10bit address,
> > > the controller has to support this mode to communicate with the
> > > device, at least that's my understanding. But we're digressing a
> > > bit. The question is not whether I2C devices can optionally use a 10
> > > bit address, but whether I3C master controller can support this mode
> > > for I2C transfers to I2C-only devices.
> >
> > By the i2c spec the 10-bit address is optional, however the 7-bit
> > address is mandatory.
> >
> > >>>
> > >>>>  > diff --git a/drivers/i3c/master/Kconfig
> > >>>> b/drivers/i3c/master/Kconfig
> > >>>>> new file mode 100644
> > >>>>> index 000000000000..e69de29bb2d1 diff --git
> > >>>>> a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile new
> > >>>>> file mode 100644 index
> > >>>>> 000000000000..e69de29bb2d1 diff --git a/include/linux/i3c/ccc.h
> > >>>>> b/include/linux/i3c/ccc.h new file mode 100644 index
> > >>>>> 000000000000..ff3e1a3e2c4c
> > >>>>> --- /dev/null
> > >>>>> +++ b/include/linux/i3c/ccc.h
> > >>>>> @@ -0,0 +1,380 @@
> > >>>>> +/* SPDX-License-Identifier: GPL-2.0 */
> > >>>>> +/*
> > >>>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
> > >>>>> + *
> > >>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> > >>>>> + */
> > >>>>> +
> > >>>>> +
> > >>>>> +/**
> > >>>>> + * enum i3c_ccc_test_mode - enum listing all available test
> > >>>>> +modes
> > >>>>> + *
> > >>>>> + * @I3C_CCC_EXIT_TEST_MODE: exit test mode
> > >>>>> + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode  */
> > enum
> > >>>>> +i3c_ccc_test_mode {
> > >>>>> +	I3C_CCC_EXIT_TEST_MODE,
> > >>>>> +	I3C_CCC_VENDOR_TEST_MODE,
> > >>>>> +};
> > >>>>> +
> > >>>>> +/**
> > >>>>> + * struct i3c_ccc_enttm - payload passed to ENTTM CCC
> > >>>>> + *
> > >>>>> + * @mode: one of the &enum i3c_ccc_test_mode modes
> > >>>>> + *
> > >>>>> + * Information passed to the ENTTM CCC to instruct an I3C
> > >>>>> +device to enter a
> > >>>>> + * specific test mode.
> > >>>>> + */
> > >>>>> +struct i3c_ccc_enttm {
> > >>>>> +	u8 mode;
> > >>>>> +} __packed;
> > >>>>> +
> > >>>>> +/**
> > >>>>> + * struct i3c_ccc_setda - payload passed to ENTTM CCC
> > >>>>> + *
> > >>>>> + * @mode: one of the &enum i3c_ccc_test_mode modes
> > >>>>> + *
> > >>>>> + * Information passed to the ENTTM CCC to instruct an I3C
> > >>>>> +device to enter a
> > >>>>> + * specific test mode.
> > >>>>> + */
> > >>>>> +struct i3c_ccc_setda {
> > >>>>> +	u8 addr;
> > >>>>> +} __packed;
> > >>>>  what do you mean with struct? Maybe setdasa? if so, what is the
> > addr?
> > >> Do you have the function to use this structure? Because one command
> > >> use the static address and the other use the dynamic address.
> > >>
> > >>>>
> > >>>>  > +/**
> > >>>>> + * enum i3c_sdr_max_data_rate - max data rate values for
> > >>>>> +private SDR transfers  */ enum i3c_sdr_max_data_rate {
> > >>>>> +	I3C_SDR_DR_FSCL_MAX,
> > >>>>> +	I3C_SDR_DR_FSCL_8MHZ,
> > >>>>> +	I3C_SDR_DR_FSCL_6MHZ,
> > >>>>> +	I3C_SDR_DR_FSCL_4MHZ,
> > >>>>> +	I3C_SDR_DR_FSCL_2MHZ,
> > >>>>> +};
> > >>>> Can you change the names to:
> > >>>>
> > >>>> I3C_SDR0_FSCL_MAX,
> > >>>> I3C_SDR1_FSCL_8MHZ,
> > >>>> I3C_SDR2_FSCL_6MHZ,
> > >>>> I3C_SDR3_FSCL_4MHZ,
> > >>>> I3C_SDR4_FSCL_2MHZ,
> > >>>>
> > >>>> thus the data rate isn't repeated.
> > >>> What's the problem with the name I use? Moreover, I see no mention
> > >>> to the SDR0,1,2,3,4 modes in the public spec.
> > >> When you get the GETMXDS information, the maxWr and maxRd came
> > from 0
> > >> to 4, so in my opinion I think in this way is easier to have a
> relationship.
> > > It's an emum, and there's no mention of the SDRX modes you're using
> > > here in the I3C spec. I guess it's named this way in your I3C
> > > controller datasheet. I personally don't see a good reason to add
> > > SDRX in the name, but if you insist...
> >
> > The idea is to say that it is SDR mode and the value that GETMXDS
> > command return. It is what makes sense to me.
> >
> > >>>>> +
> > >>>>> +#endif /* I3C_CCC_H */
> > >>>>> diff --git a/include/linux/i3c/device.h
> > >>>>> b/include/linux/i3c/device.h new file mode 100644 index
> > >>>>> 000000000000..83958d3a02e2
> > >>>>> --- /dev/null
> > >>>>> +++ b/include/linux/i3c/device.h
> > >>>>> @@ -0,0 +1,321 @@
> > >>>>> +/* SPDX-License-Identifier: GPL-2.0 */
> > >>>>> +/*
> > >>>>> + * Copyright (C) 2017 Cadence Design Systems Inc.
> > >>>>> + *
> > >>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com>
> > >>>>> + */
> > >>>>> +
> > >>>>> +#ifndef I3C_DEV_H
> > >>>>> +#define I3C_DEV_H
> > >>>>> +
> > >>>>> +#include <linux/device.h>
> > >>>>> +#include <linux/i2c.h>
> > >>>>> +#include <linux/mod_devicetable.h> #include <linux/module.h>
> > >>>>> +
> > >>>>> +/**
> > >>>>> + * enum i3c_hdr_mode - HDR mode ids
> > >>>>> + * @I3C_HDR_DDR: DDR mode
> > >>>>> + * @I3C_HDR_TSP: TSP mode
> > >>>>> + * @I3C_HDR_TSL: TSL mode
> > >>>>> + */
> > >>>>> +enum i3c_hdr_mode {
> > >>>>> +	I3C_HDR_DDR,
> > >>>>> +	I3C_HDR_TSP,
> > >>>>> +	I3C_HDR_TSL,
> > >>>>> +};
> > >>>>> +
> > >>>>> +/**
> > >>>>> + * struct i3c_hdr_cmd - I3C HDR command
> > >>>>> + * @mode: HDR mode selected for this command
> > >>>>> + * @code: command opcode
> > >>>>> + * @addr: I3C dynamic address
> > >>>>> + * @ndatawords: number of data words (a word is 16bits wide)
> > >>>>> + * @data: input/output buffer
> > >>>>> + */
> > >>>>> +struct i3c_hdr_cmd {
> > >>>>> +	enum i3c_hdr_mode mode;
> > >>>>> +	u8 code;
> > >>>>> +	u8 addr;
> > >>>>> +	int ndatawords;
> > >>>>> +	union {
> > >>>>> +		u16 *in;
> > >>>>> +		const u16 *out;
> > >>>>> +	} data;
> > >>>>> +};
> > >> Please mention that the @code is what will define if the transfer
> > >> is read
> > or write.
> > > Well, I think it's pretty clear in the definition you'll find in the
> > > ccc.h file, but I can add a comment here too if you like.
> >
> > I don't find it in ccc.h file. Anyway is not good to put this
> > definition there because is not related.
> >
> > >>>>> +
> > >>>>> +/* Private SDR read transfer */
> > >>>>> +#define I3C_PRIV_XFER_READ		BIT(0)
> > >>>>> +/*
> > >>>>> + * Instruct the controller to issue a STOP after a specific
> > >>>>> +transfer instead
> > >>>>> + * of a REPEATED START.
> > >>>>> + */
> > >>>>> +#define I3C_PRIV_XFER_STOP		BIT(1)
> > >>>>> +
> > >>>>> +/**
> > >>>>> + * struct i3c_priv_xfer - I3C SDR private transfer
> > >>>>> + * @addr: I3C dynamic address
> > >>>>> + * @len: transfer length in bytes of the transfer
> > >>>>> + * @flags: combination of I3C_PRIV_XFER_xxx flags
> > >>>>> + * @data: input/output buffer
> > >>>>> + */
> > >>>>> +struct i3c_priv_xfer {
> > >>>>> +	u8 addr;
> > >>>>> +	u16 len;
> > >>>>> +	u32 flags;
> > >>>>> +	struct {
> > >>>>> +		void *in;
> > >>>>> +		const void *out;
> > >>>>> +	} data;
> > >>>>> +};
> > >>>>  Same as above, i3c_sdr_max_data_rate to change the bus scl.
> > >>> If I'm understanding the spec correctly, that's not something you
> > >>> want to change on a per-transfer basis. The constraint is on the
> > >>> device itself and should IMO not be part of the i3c_priv_xfer struct.
> > >> As mention before this is important.
> > >> You can do the same as for struct i3c_hdr_cmd and add a enum
> > i3c_sdr_max_data_rate.
> > >>
> > >> The @flag only have 2 bits of load, is the rest opened?
> > > If by open you mean that we can add more flags if we need to, then yes.
> > >
> > >>>
> > >>>>  > +
> > >>>>> +/**
> > >>>>> + * enum i3c_dcr - I3C DCR values
> > >>>>> + * @I3C_DCR_GENERIC_DEVICE: generic I3C device  */ enum
> i3c_dcr
> > {
> > >>>>> +	I3C_DCR_GENERIC_DEVICE = 0,
> > >>>>> +};
> > >>>>> +
> > >>>>> +#define I3C_PID_MANUF_ID(pid)		(((pid) &
> > GENMASK_ULL(47, 33)) >> 33)
> > >>>>> +#define I3C_PID_RND_LOWER_32BITS(pid)	(!!((pid) &
> > BIT_ULL(32)))
> > >>>>> +#define I3C_PID_RND_VAL(pid)		((pid) &
> GENMASK_ULL(31,
> > 0))
> > >>>>> +#define I3C_PID_PART_ID(pid)		(((pid) &
> GENMASK_ULL(31,
> > 16)) >> 16)
> > >>>>> +#define I3C_PID_INSTANCE_ID(pid)	(((pid) & GENMASK_ULL(15,
> > 12)) >> 12)
> > >>>>> +#define I3C_PID_EXTRA_INFO(pid)		((pid) &
> > GENMASK_ULL(11, 0))
> > >>>>> +
> > >>>>> +#define I3C_BCR_DEVICE_ROLE(bcr)	((bcr) & GENMASK(7, 6))
> > >>>>> +#define I3C_BCR_I3C_SLAVE		(0 << 6)
> > >>>>> +#define I3C_BCR_I3C_MASTER		(1 << 6)
> > >>>>> +#define I3C_BCR_HDR_CAP			BIT(5)
> > >>>>> +#define I3C_BCR_BRIDGE			BIT(4)
> > >>>>> +#define I3C_BCR_OFFLINE_CAP		BIT(3)
> > >>>>> +#define I3C_BCR_IBI_PAYLOAD		BIT(2)
> > >>>>> +#define I3C_BCR_IBI_REQ_CAP		BIT(1)
> > >>>>> +#define I3C_BCR_MAX_DATA_SPEED_LIM	BIT(0)
> > >>>>> +
> > >>>>> +/**
> > >>>>> + * struct i3c_device_info - I3C device information
> > >>>>> + * @pid: Provisional ID
> > >>>>> + * @bcr: Bus Characteristic Register
> > >>>>> + * @dcr: Device Characteristic Register
> > >>>>> + * @static_addr: static/I2C address
> > >>>>> + * @dyn_addr: dynamic address
> > >>>>> + * @hdr_cap: supported HDR modes
> > >>>>> + * @max_read_ds: max read speed information
> > >>>>> + * @max_write_ds: max write speed information
> > >>>>> + * @max_ibi_len: max IBI payload length
> > >>>>> + * @max_read_turnaround: max read turn-around time in
> > >>>>> +micro-seconds
> > >>>>> + * @max_read_len: max private SDR read length in bytes
> > >>>>> + * @max_write_len: max private SDR write length in bytes
> > >>>>> + *
> > >>>>> + * These are all basic information that should be advertised by
> > >>>>> +an
> > I3C device.
> > >>>>> + * Some of them are optional depending on the device type and
> > >>>>> +device
> > >>>>> + * capabilities.
> > >>>>> + * For each I3C slave attached to a master with
> > >>>>> + * i3c_master_add_i3c_dev_locked(), the core will send the
> > >>>>> +relevant CCC command
> > >>>>> + * to retrieve these data.
> > >>>>> + */
> > >>>>> +struct i3c_device_info {
> > >>>>> +	u64 pid;
> > >>>>> +	u8 bcr;
> > >>>>> +	u8 dcr;
> > >>>>> +	u8 static_addr;
> > >>>>> +	u8 dyn_addr;
> > >>>>> +	u8 hdr_cap;
> > >>>>> +	u8 max_read_ds;
> > >>>>> +	u8 max_write_ds;
> > >>>>> +	u8 max_ibi_len;
> > >>>>> +	u32 max_read_turnaround;
> > >>>>> +	u16 max_read_len;
> > >>>>> +	u16 max_write_len;
> > >>>>> +};
> > >>>>> +
> > >>>>  is this information filled with data provided from CCC commands?
> > >>> Yes, they are.
> > >> Ok, them the intention is to do this on bus_init(), right?
> > > Not only, it can be after a Hot-Join, or after the user has
> > > triggered a new DAA. Anyway, these information are retrieved anytime
> > > you add a device with i3c_master_add_i3c_dev_locked(), and the core
> > > uses CCC commands to do that.
> > >
> > >>>>> +
> > >>>>> +/**
> > >>>>> + * struct i3c_master_controller_ops - I3C master methods
> > >>>>> + * @bus_init: hook responsible for the I3C bus initialization. This
> > >>>>> + *	      initialization should follow the steps described in the I3C
> > >>>>> + *	      specification. This hook is called with the bus lock held
> > in
> > >>>>> + *	      write mode, which means all _locked() helpers can safely
> > be
> > >>>>> + *	      called from there
> > >>>>> + * @bus_cleanup: cleanup everything done in
> > >>>>> + *		 &i3c_master_controller_ops->bus_init(). This
> > function is
> > >>>>> + *		 optional and should only be implemented if
> > >>>>> + *		 &i3c_master_controller_ops->bus_init() attached
> > private data
> > >>>>> + *		 to I3C/I2C devices. This hook is called with the bus
> > lock
> > >>>>> + *		 held in write mode, which means all _locked()
> > helpers can
> > >>>>> + *		 safely be called from there
> > >>>>> + * @supports_ccc_cmd: should return true if the CCC command is
> > supported, false
> > >>>>> + *		      otherwise
> > >>>>> + * @send_ccc_cmd: send a CCC command
> > >>>>> + * @send_hdr_cmds: send one or several HDR commands. If there
> > >>>>> + is
> > more than one
> > >>>>> + *		   command, they should ideally be sent in the same
> > HDR
> > >>>>> + *		   transaction
> > >>>>> + * @priv_xfers: do one or several private I3C SDR transfers
> > >>>>> + * @i2c_xfers: do one or several I2C transfers
> > >>>>> + * @request_ibi: attach an IBI handler to an I3C device. This
> > >>>>> + implies
> > defining
> > >>>>> + *		 an IBI handler and the constraints of the IBI
> > (maximum payload
> > >>>>> + *		 length and number of pre-allocated slots).
> > >>>>> + *		 Some controllers support less IBI-capable devices
> > than regular
> > >>>>> + *		 devices, so this method might return -%EBUSY if
> > there's no
> > >>>>> + *		 more space for an extra IBI registration
> > >>>>> + * @free_ibi: free an IBI previously requested with ->request_ibi().
> > The IBI
> > >>>>> + *	      should have been disabled with ->disable_irq() prior to
> > that
> > >>>>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi()
> > >>>>> + has been
> > called
> > >>>>> + *		prior to ->enable_ibi(). The controller should first
> > enable
> > >>>>> + *		the IBI on the controller end (for example, unmask
> > the hardware
> > >>>>> + *		IRQ) and then send the ENEC CCC command (with
> > the IBI flag set)
> > >>>>> + *		to the I3C device
> > >>>>> + * @disable_ibi: disable an IBI. First send the DISEC CCC
> > >>>>> + command
> > with the IBI
> > >>>>> + *		 flag set and then deactivate the hardware IRQ on
> > the
> > >>>>> + *		 controller end
> > >>>>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an
> > >>>>> + IBI has
> > been
> > >>>>> + *		      processed by its handler. The IBI slot should be
> > put back
> > >>>>> + *		      in the IBI slot pool so that the controller can re-
> > use it
> > >>>>> + *		      for a future IBI
> > >>>>> + *
> > >>>>> + * One of the most important hooks in these ops is
> > >>>>> + * &i3c_master_controller_ops->bus_init(). Here is a
> > >>>>> +non-exhaustive list of
> > >>>>> + * things that should be done in &i3c_master_controller_ops-
> > >bus_init():
> > >>>>> + *
> > >>>>> + * 1) call i3c_master_set_info() with all information
> > >>>>> +describing the master
> > >>>>> + * 2) ask all slaves to drop their dynamic address by sending
> > >>>>> +the
> > RSTDAA CCC
> > >>>>> + *    with i3c_master_rstdaa_locked()
> > >>>>> + * 3) ask all slaves to disable IBIs using
> > >>>>> +i3c_master_disec_locked()
> > >>>>> + * 4) start a DDA procedure by sending the ENTDAA CCC with
> > >>>>> + *    i3c_master_entdaa_locked(), or using the internal DAA logic
> > provided by
> > >>>>> + *    your controller
> > >>>> You mean SETDASA CCC command?
> > >>> No, I really mean ENTDAA and DAA. By internal DAA logic I mean
> > >>> that some controllers are probably automating the whole DAA
> > >>> procedure, while others may let the SW control every step.
> > >> My understanding is that i3c_master_entdaa_locked() will trigger
> > >> the DAA process and DAA can be done by SETDASA, ENTDAA and later
> > >> after the bus initialization with SETNEWDA.
> > > No. Only ENTDAA can trigger a DAA procedure. SETDASA is here to
> > > assign a single dynamic address to a device that already has a
> > > static address but no dynamic address yet, and SETNEWDA is here to
> > > modify the
> > dynamic
> > > address of a device that already has one.
> >
> > >> I think the DAA process should be more generic, right now is only
> > >> made through the ENTDAA command with (cmd.ndests = 1).
> > >> I mean, shouldn't this be made by the core? First doing DAA for the
> > >> devices declared and them try do discover the rest of devices on the
> bus.
> > > Can you detail a bit more? If the only part you're complaining about
> > > is pre-assignment of dynamic addresses with SETDASA when a device is
> > > declared in the DT with a reg and dynamic-address property, then
> > > yes, I think I can provide an helper for that. But this helper would
> > > still have to be called from the master controller driver (from
> > > ->bus_init() or after a Hot-Join).
> > >
> > > Now, if the question is, is there a way we can automate things even
> > > more and completely implement DAA from the core? I doubt it, because
> > > the way the core will trigger DAA, expose discovered devices or
> > > allow you to declare manually assigned addresses is likely to be
> > > controller-dependent.
> >
> > Please refer to figure 90 of public specification. As you can see the
> > DAA process should start with SETDASA command.
> >
> > With the current flow of this patch the DAA process is limited to
> > ENTDAA command only.
> >
> > > When I designed the framework I took the decision to base my work on
> > > the spec rather than focusing on the I3C master controller I had to
> > > support (Cadence). This is the reason I decided to keep the
> > > interface as simple as possible at the risk of encouraging
> > > code-duplication (at
> > > first) rather than coming up with an interface that is designed with
> > > a single controller in mind and having to break things every time a
> > > new controller comes out.
> > >
> > > Thank you for you comments, but I'd like to know if some of my
> > > design choices are blocking you to support your controller. What
> > > I've seen so far is a collection of things that might be relevant to
> > > fix (though most of them are subject to interpretation and/or a
> > > matter of taste), but nothing that should really block you.
> > >
> > > Can you clarify that, and maybe come back with a list of things that
> > > you think are preventing you from properly supporting the Synopsys
> > > controller?
> > >
> > > Thanks,
> > >
> > > Boris
> >
> > As you can check from my  comments my concerns are about the i3c
> > specification without the controller in mind.
> >
> > Best regards,
> > Vitor Soares
> >


^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-27 16:03           ` Vitor Soares
  2018-02-27 16:43             ` Przemyslaw Sroka
@ 2018-02-27 19:57             ` Boris Brezillon
  1 sibling, 0 replies; 50+ messages in thread
From: Boris Brezillon @ 2018-02-27 19:57 UTC (permalink / raw)
  To: Vitor Soares
  Cc: Boris Brezillon, Wolfram Sang, linux-i2c, Jonathan Corbet,
	linux-doc, Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

Hi Vitor,

On Tue, 27 Feb 2018 16:03:58 +0000
Vitor Soares <Vitor.Soares@synopsys.com> wrote:

> >>>
> >>> The speed R/W speed limitation is encoded in the device object, so, if
> >>> the controller has to configure that on a per-transfer basis, one
> >>> solution would be to pass the device to the ->priv_xfers().    
> >> The speed R/W limitation is only for private transfers. Also the device can have
> >> a limitation to write and not for read data.
> >> This information is obtained with the command GETMXDS which returns the Maximum
> >> Sustained Data Rate for non-CCC messages.  
> > And that's exactly what I expose in i3c_device_info, which is embedded
> > in i3c_device, so you should have all the information you need to
> > determine the speed in the controller driver if ->priv_xfer() is passed
> > the device attached to those transfers. Would that be okay if we pass an
> > i3c_device object to ->priv_xfers()?  
> 
> If you pass the i3c_device to ->priv_xfer(), then you won't need the address too.

That's true. So how about we pass the i3c_device to ->priv_xfer() and
drop the address field in i3c_priv_xfer. Or we could remove the address
field add an i3c_device pointer in i3c_priv_xfer, this way, if we ever
need to do cross-device sequence we'll be able to support it.

> 
> Maybe someone else can give other point of view.

That'd be great, but I'd like to hear your opinion, because it's not
clear to me what you think of my suggestion.


> >> Either important is the SETDASA for declared I3C devices. So the DAA process
> >> should start by send an SETDASA and them ENTDAA CCC command.  
> > My understanding was that SETDASA was not mandatory, and was only useful
> > when one wants to assign a specific dynamic address to a slave that has
> > a static address (which is again not mandatory).
> > I've tested it, and even devices with a static address participate to
> > the DAA procedure if they've not been assigned a dynamic address yet,
> > so I don't see the need for this SETDASA step if you don't need to
> > assign a particular dynamic address to the device.
> >
> > Could you tell me why you think SETDASA is required?  
> 
> Yes, you are right... But in my opinion it is required as it does part of DAA
> process.

As Przemek said in his reply, I don't think it's required, at least not
for the initial implementation. I'm definitely not saying we should
never support the feature, but it can easily be added afterwards.

BTW, can you give me a scenario where you'll want to assign a specific
dynamic address to a device before DAA takes place (by DAA, I mean what
happens after ENTDAA, which AIUI is what DAA describes)? I know it's
described in the spec, and might become useful at some point, but right
now, for a general purpose OS like Linux, I don't see a good reason to
assign a dynamic address using SETDASA.

> 
> >>>>> +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap)
> >>>>> +{
> >>>>> +	return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR;
> >>>>> +}      
> >>>>  Is I2C_FUNC_10BIT_ADDR allowed ?    
> >>> According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes (at
> >>> least that my understanding). And the Cadence controller supports it.    
> >> The table say the oposite. The I2C extended address feature is not used on I3C
> >> bus, thus this feature shall be disable.  
> > Actually, I was wrong when initially mentioning this table: it's about
> > I2C features supported on I3C slaves, so not really what we're looking
> > for. Here, we're wondering if I2C-only devices can have 10-bit
> > addresses. The Cadence controller supports that, so there's probably
> > nothing preventing use of 10-bit addresses for I2C transfers, but maybe
> > not all I3C master controllers support that, so we should probably
> > let the I3C master driver implement this method.  
> 
> The spec says that is "not used" so it will not interface with I3C bus.

Again, I should not have pointed you to this chapter, because it does
not describe what the I3C bus accept, but what I3C slave acting like
I2C devices accept (basically what they accept before being assigned a
dynamic address).

If you see in the I3C spec that I2C transfers using 10-bit addresses
is forbidden, could you tell me where it's stated, because I didn't
find it. 

> 
> >> BTW it is optional on I2C devices.  
> > You mean I2C controllers? When an I2C device has a 10bit address, the
> > controller has to support this mode to communicate with the device, at
> > least that's my understanding. But we're digressing a bit. The
> > question is not whether I2C devices can optionally use a 10 bit
> > address, but whether I3C master controller can support this mode for
> > I2C transfers to I2C-only devices.  
> 
> By the i2c spec the 10-bit address is optional, however the 7-bit address is
> mandatory.

The controller is not forced to support this feature, I think I already
said I agree on this aspect. But if you have a device with a 10-bit
address, it has to be connected to a controller that supports this
feature otherwise it won't work.

So, let's sum-up: I3C controllers can support I2C transfers with 10bit
addresses, but this feature should be optional. I think we might also
want to support optimized smbus methods, so maybe we should just let
I3C controllers fill the i2c_adapter object as they wish.


> >>>>> +/**
> >>>>> + * struct i3c_ccc_setda - payload passed to ENTTM CCC
> >>>>> + *
> >>>>> + * @mode: one of the &enum i3c_ccc_test_mode modes
> >>>>> + *
> >>>>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
> >>>>> + * specific test mode.
> >>>>> + */
> >>>>> +struct i3c_ccc_setda {
> >>>>> +	u8 addr;
> >>>>> +} __packed;      
> >>>>  what do you mean with struct? Maybe setdasa? if so, what is the addr?    
> >> Do you have the function to use this structure? Because one command use the
> >> static address and the other use the dynamic address.

Forgot to answer this one in my previous reply. Unicast CCC commands
are always passed the destination in i3c_ccc_cmd->dest[x].addr, so, in
case of SETDASA, i3c_ccc_cmd->dest[x].addr will be the static address,
and in case of SETNEWDA i3c_ccc_cmd->dest[x].addr will be the old
dynamic address. In both cases, the payload will be a single byte
describing the new dynamic address, hence the common i3c_ccc_setda
struct.

> >>  
> >>>>    
> >>>>  > +/**
> >>>>> + * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers
> >>>>> + */
> >>>>> +enum i3c_sdr_max_data_rate {
> >>>>> +	I3C_SDR_DR_FSCL_MAX,
> >>>>> +	I3C_SDR_DR_FSCL_8MHZ,
> >>>>> +	I3C_SDR_DR_FSCL_6MHZ,
> >>>>> +	I3C_SDR_DR_FSCL_4MHZ,
> >>>>> +	I3C_SDR_DR_FSCL_2MHZ,
> >>>>> +};      
> >>>> Can you change the names to:
> >>>>
> >>>> I3C_SDR0_FSCL_MAX,
> >>>> I3C_SDR1_FSCL_8MHZ,
> >>>> I3C_SDR2_FSCL_6MHZ,
> >>>> I3C_SDR3_FSCL_4MHZ,
> >>>> I3C_SDR4_FSCL_2MHZ,
> >>>>
> >>>> thus the data rate isn't repeated.    
> >>> What's the problem with the name I use? Moreover, I see no mention to
> >>> the SDR0,1,2,3,4 modes in the public spec.    
> >> When you get the GETMXDS information, the maxWr and maxRd came from 0 to 4, so
> >> in my opinion I think in this way is easier to have a relationship.  
> > It's an emum, and there's no mention of the SDRX modes you're using
> > here in the I3C spec. I guess it's named this way in your I3C
> > controller datasheet. I personally don't see a good reason to add SDRX
> > in the name, but if you insist...  
> 
> The idea is to say that it is SDR mode and the value that GETMXDS command
> return. It is what makes sense to me.

Still don't see why this is needed, since what we care about here is
the actual max SCL frequency, which is given in the enum name. But I
don't want to argue more on this minor aspect, so, if everyone is okay,
I'll switch to your solution.

> >>>>> +
> >>>>> +/**
> >>>>> + * struct i3c_hdr_cmd - I3C HDR command
> >>>>> + * @mode: HDR mode selected for this command
> >>>>> + * @code: command opcode
> >>>>> + * @addr: I3C dynamic address
> >>>>> + * @ndatawords: number of data words (a word is 16bits wide)
> >>>>> + * @data: input/output buffer
> >>>>> + */
> >>>>> +struct i3c_hdr_cmd {
> >>>>> +	enum i3c_hdr_mode mode;
> >>>>> +	u8 code;
> >>>>> +	u8 addr;
> >>>>> +	int ndatawords;
> >>>>> +	union {
> >>>>> +		u16 *in;
> >>>>> +		const u16 *out;
> >>>>> +	} data;
> >>>>> +};    
> >> Please mention that the @code is what will define if the transfer is read or write.  
> > Well, I think it's pretty clear in the definition you'll find in the
> > ccc.h file, but I can add a comment here too if you like.  
> 
> I don't find it in ccc.h file. Anyway is not good to put this definition there
> because is not related.

Oops! Sorry, I mixed the CCC and HDR stuff. It's indeed not clear that
@code defines the transfer direction. I'll clarify this aspect. 
 
> >> I think the DAA process should be more generic, right now is only made through
> >> the ENTDAA command with (cmd.ndests = 1).
> >> I mean, shouldn't this be made by the core? First doing DAA for the devices
> >> declared and them try do discover the rest of devices on the bus.  
> > Can you detail a bit more? If the only part you're complaining about is
> > pre-assignment of dynamic addresses with SETDASA when a device is
> > declared in the DT with a reg and dynamic-address property, then yes, I
> > think I can provide an helper for that. But this helper would still have
> > to be called from the master controller driver (from ->bus_init() or
> > after a Hot-Join).
> >
> > Now, if the question is, is there a way we can automate things even more
> > and completely implement DAA from the core? I doubt it, because the way
> > the core will trigger DAA, expose discovered devices or allow you to
> > declare manually assigned addresses is likely to be
> > controller-dependent.  
> 
> Please refer to figure 90 of public specification. As you can see the DAA
> process should start with SETDASA command.

Only if devices with a static address needs to be assigned a specific
dynamic address. At least, that's my understanding. Are there plans to
create devices that would only reply to SETDASA commands but ignore
ENTDAA ones?

> 
> With the current flow of this patch the DAA process is limited to ENTDAA command
> only.

As a first step, yes. But again, nothing is set in stone, and the
SETDASA step can be added afterwards. As said above, I fail to see a
use case where it's really required (note that I said required, not
useful).

> 
> > When I designed the framework I took the decision to base my work on the
> > spec rather than focusing on the I3C master controller I had to support
> > (Cadence). This is the reason I decided to keep the interface as simple
> > as possible at the risk of encouraging code-duplication (at first)
> > rather than coming up with an interface that is designed with a single
> > controller in mind and having to break things every time a new
> > controller comes out.
> >
> > Thank you for you comments, but I'd like to know if some of my design
> > choices are blocking you to support your controller. What I've seen so
> > far is a collection of things that might be relevant to fix (though
> > most of them are subject to interpretation and/or a matter of taste),
> > but nothing that should really block you.
> >
> > Can you clarify that, and maybe come back with a list of things that you
> > think are preventing you from properly supporting the Synopsys
> > controller?
> >
> > Thanks,
> >
> > Boris   
> 
> As you can check from my  comments my concerns are about the i3c specification
> without the controller in mind.

Okay, then we're on the same page.

Regards,

Boris

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-27 16:43             ` Przemyslaw Sroka
  2018-02-27 17:06               ` Przemyslaw Sroka
@ 2018-02-27 20:13               ` Boris Brezillon
  2018-02-27 20:24                 ` Przemyslaw Sroka
  1 sibling, 1 reply; 50+ messages in thread
From: Boris Brezillon @ 2018-02-27 20:13 UTC (permalink / raw)
  To: Przemyslaw Sroka
  Cc: Vitor Soares, Boris Brezillon, Wolfram Sang, linux-i2c,
	Jonathan Corbet, linux-doc, Greg Kroah-Hartman, Arnd Bergmann,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

Hi Przemek,

On Tue, 27 Feb 2018 16:43:27 +0000
Przemyslaw Sroka <psroka@cadence.com> wrote:

> >   
> > >> Either important is the SETDASA for declared I3C devices. So the DAA
> > >> process should start by send an SETDASA and them ENTDAA CCC  
> > command.  
> > > My understanding was that SETDASA was not mandatory, and was only
> > > useful when one wants to assign a specific dynamic address to a slave
> > > that has a static address (which is again not mandatory).
> > > I've tested it, and even devices with a static address participate to
> > > the DAA procedure if they've not been assigned a dynamic address yet,
> > > so I don't see the need for this SETDASA step if you don't need to
> > > assign a particular dynamic address to the device.
> > >
> > > Could you tell me why you think SETDASA is required?  
> > 
> > Yes, you are right... But in my opinion it is required as it does part of DAA
> > process.  
> 
> SETDASA is simply faster than ENTDAA, but only if there is no need to
> collect BCR/DCR/PID of such devices. I think most applications would
> like to have them as an status information so  after all ENTDAA can 
> be regarded as an generic approach (unless I'm mistaken).

Actually, we could retrieve BCR/DCR/PID (and all other relevant
information, like MAXDS) even with the SETDASA approach. We just
need to send the according CCC commands after SETDASA.

But that's also my understanding that ENTDAA should always work, and
SETDASA usage is only needed if you want to reserve a dynamic address
and assign it to a device before DAA takes place. This way you can
enforce the device priority (WRT IBIs). But honestly, that's the only
use case I can think of, and to me, it sounds like an advanced feature
we may want to support at some point, but don't need in the initial
implementation.

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 50+ messages in thread

* RE: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-27 20:13               ` Boris Brezillon
@ 2018-02-27 20:24                 ` Przemyslaw Sroka
  2018-02-27 21:14                   ` Boris Brezillon
  0 siblings, 1 reply; 50+ messages in thread
From: Przemyslaw Sroka @ 2018-02-27 20:24 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Vitor Soares, Boris Brezillon, Wolfram Sang, linux-i2c,
	Jonathan Corbet, linux-doc, Greg Kroah-Hartman, Arnd Bergmann,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

Hi Boris

> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> Sent: Tuesday, February 27, 2018 9:13 PM
> To: Przemyslaw Sroka <psroka@cadence.com>
> Cc: Vitor Soares <Vitor.Soares@synopsys.com>; Boris Brezillon
> <boris.brezillon@free-electrons.com>; Wolfram Sang <wsa@the-
> dreams.de>; linux-i2c@vger.kernel.org; Jonathan Corbet <corbet@lwn.net>;
> linux-doc@vger.kernel.org; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Arnd Bergmann <arnd@arndb.de>;
> Arkadiusz Golec <agolec@cadence.com>; Alan Douglas
> <adouglas@cadence.com>; Bartosz Folta <bfolta@cadence.com>; Damian
> Kos <dkos@cadence.com>; Alicja Jurasik-Urbaniak <alicja@cadence.com>;
> Cyprian Wronka <cwronka@cadence.com>; Suresh Punnoose
> <sureshp@cadence.com>; Thomas Petazzoni <thomas.petazzoni@free-
> electrons.com>; Nishanth Menon <nm@ti.com>; Rob Herring
> <robh+dt@kernel.org>; Pawel Moll <pawel.moll@arm.com>; Mark Rutland
> <mark.rutland@arm.com>; Ian Campbell <ijc+devicetree@hellion.org.uk>;
> Kumar Gala <galak@codeaurora.org>; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; Geert Uytterhoeven <geert@linux-m68k.org>; Linus
> Walleij <linus.walleij@linaro.org>
> Subject: Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
> 
> EXTERNAL MAIL
> 
> 
> Hi Przemek,
> 
> On Tue, 27 Feb 2018 16:43:27 +0000
> Przemyslaw Sroka <psroka@cadence.com> wrote:
> 
> > >
> > > >> Either important is the SETDASA for declared I3C devices. So the
> > > >> DAA process should start by send an SETDASA and them ENTDAA
> CCC
> > > command.
> > > > My understanding was that SETDASA was not mandatory, and was
> only
> > > > useful when one wants to assign a specific dynamic address to a
> > > > slave that has a static address (which is again not mandatory).
> > > > I've tested it, and even devices with a static address participate
> > > > to the DAA procedure if they've not been assigned a dynamic
> > > > address yet, so I don't see the need for this SETDASA step if you
> > > > don't need to assign a particular dynamic address to the device.
> > > >
> > > > Could you tell me why you think SETDASA is required?
> > >
> > > Yes, you are right... But in my opinion it is required as it does
> > > part of DAA process.
> >
> > SETDASA is simply faster than ENTDAA, but only if there is no need to
> > collect BCR/DCR/PID of such devices. I think most applications would
> > like to have them as an status information so  after all ENTDAA can be
> > regarded as an generic approach (unless I'm mistaken).
> 
> Actually, we could retrieve BCR/DCR/PID (and all other relevant
> information, like MAXDS) even with the SETDASA approach. We just need to
> send the according CCC commands after SETDASA.
> 
I agree, what I meant by "SETDASA is simply faster than ENTDAA, but only if there is no need to collect BCR/DCR/PID of such devices." Is that it is faster than DAA but only if not followed by GET CCC commands to gather BCR/DCR/PID. I think we are on the same page here.

> But that's also my understanding that ENTDAA should always work, and
> SETDASA usage is only needed if you want to reserve a dynamic address
> and assign it to a device before DAA takes place. This way you can enforce
> the device priority (WRT IBIs). But honestly, that's the only use case I can
> think of, and to me, it sounds like an advanced feature we may want to
> support at some point, but don't need in the initial implementation.
>
Still ENTDAA seems to be sufficient for IBI prioritization but I can imagine some use cases where people would like to use it for such purposes. Note that SETDASA is applicable only for devices with SA so it is self-explanatory that it cannot be considered as utility to define priorities for all devices before ENTDAA. 

> --
> Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and
> Kernel engineering https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__bootlin.com&d=DwICAg&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3G
> Z-_haXqY&r=b0WPdqYyu0KH4-vSatt-ViJE1riZ603zdXl3hHHp_TU&m=wM54-
> BGcSfHEklVRsw02O-bnyNkLTe9c0RyBP_ExzPA&s=pxQrogG-
> Nq4XOMU7SPZ2FZNbgnbnjdERtMm_h7ZcdCE&e=

Regards,
Przemek

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-27 17:06               ` Przemyslaw Sroka
@ 2018-02-27 20:25                 ` Boris Brezillon
  0 siblings, 0 replies; 50+ messages in thread
From: Boris Brezillon @ 2018-02-27 20:25 UTC (permalink / raw)
  To: Przemyslaw Sroka
  Cc: Vitor Soares, Boris Brezillon, Wolfram Sang, linux-i2c,
	Jonathan Corbet, linux-doc, Greg Kroah-Hartman, Arnd Bergmann,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

Hi Przemek,

On Tue, 27 Feb 2018 17:06:37 +0000
Przemyslaw Sroka <psroka@cadence.com> wrote:

> > > >
> > > > Could you tell me why you think SETDASA is required?  
> > >
> > > Yes, you are right... But in my opinion it is required as it does part
> > > of DAA process.  
> > 
> > SETDASA is simply faster than ENTDAA, but only if there is no need to
> > collect BCR/DCR/PID of such devices. I think most applications would like to
> > have them as an status information so  after all ENTDAA can be regarded as
> > an generic approach (unless I'm mistaken).  
> 
> Below are 2 examples on how DAA can be executed:
> 1st:
> A1) SETDASA to devices with SA

I'm not even sure all devices with a static address needs to be
assigned a dynamic address with SETDASA (actually, I'm almost sure
it's not the case, since, according to section "5.1.9.3 CCC Command
Definitions" of the spec, all I3C slaves have to support ENTDAA). To me,
it looks like you'd want to do that only is you really need to reserve
a specific dynamic address and prevent the DAA step from assigning it
to another device.

> B1) DAA to remaining devices
> C1) GET BCR/DCR/PID to devices that initially had SA
> NOTES: C1 is optional and order of B1 and C1 can be changed

While that's true in principle, in Linux we'll always retrieve
BCR/DCR/PID (and more, like MAXDS), no matter how the device obtained
its dynamic address.

> 
> 2nd:
> A2) DAA to all devices
> NOTES: no need for any follow up steps as all information is collected during DAA

As said above, that's not exactly how the Linux implementation works.
Right now I'm ignoring the information retrieved during DAA and forcing
a GETPID/GETBCR/GETDCR for every discovered device. This approach is
generating a bit more traffic on the bus, but it also makes the
implementation more generic, because we have a single function to add
an I3C device, no matter how it's been assigned a dynamic address.

> 
> As we can see 2nd approach is more generic and do not see any reason to add special handling for SETDASA unless there is any reasonable reason to do otherwise.

I agree on one thing: as long as you don't have to reserve a specific
dynamic address, SETDASA is not required. At least, that's my
understanding.

Regards,

Boris

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 50+ messages in thread

* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
  2018-02-27 20:24                 ` Przemyslaw Sroka
@ 2018-02-27 21:14                   ` Boris Brezillon
  0 siblings, 0 replies; 50+ messages in thread
From: Boris Brezillon @ 2018-02-27 21:14 UTC (permalink / raw)
  To: Przemyslaw Sroka
  Cc: Vitor Soares, Boris Brezillon, Wolfram Sang, linux-i2c,
	Jonathan Corbet, linux-doc, Greg Kroah-Hartman, Arnd Bergmann,
	Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
	Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
	Thomas Petazzoni, Nishanth Menon, Rob Herring, Pawel Moll,
	Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel,
	Geert Uytterhoeven, Linus Walleij

On Tue, 27 Feb 2018 20:24:43 +0000
Przemyslaw Sroka <psroka@cadence.com> wrote:


> > > SETDASA is simply faster than ENTDAA, but only if there is no
> > > need to collect BCR/DCR/PID of such devices. I think most
> > > applications would like to have them as an status information so
> > > after all ENTDAA can be regarded as an generic approach (unless
> > > I'm mistaken).  
> > 
> > Actually, we could retrieve BCR/DCR/PID (and all other relevant
> > information, like MAXDS) even with the SETDASA approach. We just
> > need to send the according CCC commands after SETDASA.
> >   
> I agree, what I meant by "SETDASA is simply faster than ENTDAA, but
> only if there is no need to collect BCR/DCR/PID of such devices." Is
> that it is faster than DAA but only if not followed by GET CCC
> commands to gather BCR/DCR/PID. I think we are on the same page here.

Yes, but right now it's not the case, see my other reply ;-).

> 
> > But that's also my understanding that ENTDAA should always work, and
> > SETDASA usage is only needed if you want to reserve a dynamic
> > address and assign it to a device before DAA takes place. This way
> > you can enforce the device priority (WRT IBIs). But honestly,
> > that's the only use case I can think of, and to me, it sounds like
> > an advanced feature we may want to support at some point, but don't
> > need in the initial implementation. 
> Still ENTDAA seems to be sufficient for IBI prioritization but I can
> imagine some use cases where people would like to use it for such
> purposes. Note that SETDASA is applicable only for devices with SA so
> it is self-explanatory that it cannot be considered as utility to
> define priorities for all devices before ENTDAA. 

We have SETNEWDA for other use cases: say you want one of your device to
have an higher priority, you can just manually set a new dynamic
address that is lower than any other devices on the bus (I plan to
expose that through sysfs, by making the address file writable).

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 50+ messages in thread

end of thread, other threads:[~2018-02-27 21:14 UTC | newest]

Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-14 15:16 [PATCH v2 0/7] Add the I3C subsystem Boris Brezillon
2017-12-14 15:16 ` [PATCH v2 1/7] i2c: Export of_i2c_get_board_info() Boris Brezillon
2017-12-14 15:16 ` [PATCH v2 2/7] i3c: Add core I3C infrastructure Boris Brezillon
2017-12-17 22:32   ` Randy Dunlap
2017-12-18  8:37     ` Boris Brezillon
2017-12-18 18:22       ` Randy Dunlap
2017-12-19  8:52   ` Greg Kroah-Hartman
2017-12-19  9:09     ` Boris Brezillon
2017-12-19  9:13       ` Boris Brezillon
2017-12-19  9:21         ` Greg Kroah-Hartman
2017-12-19  9:28           ` Boris Brezillon
2017-12-19  9:36             ` Greg Kroah-Hartman
2018-02-21 14:22               ` Boris Brezillon
2018-02-21 14:38                 ` Greg Kroah-Hartman
2018-02-23 16:28   ` Vitor Soares
2018-02-23 16:56   ` Vitor Soares
2018-02-23 20:30     ` Boris Brezillon
2018-02-26 18:58       ` Vitor Soares
2018-02-26 20:36         ` Boris Brezillon
2018-02-26 20:40           ` Boris Brezillon
2018-02-26 21:38             ` Boris Brezillon
2018-02-27 16:03           ` Vitor Soares
2018-02-27 16:43             ` Przemyslaw Sroka
2018-02-27 17:06               ` Przemyslaw Sroka
2018-02-27 20:25                 ` Boris Brezillon
2018-02-27 20:13               ` Boris Brezillon
2018-02-27 20:24                 ` Przemyslaw Sroka
2018-02-27 21:14                   ` Boris Brezillon
2018-02-27 19:57             ` Boris Brezillon
2018-02-23 22:45     ` Boris Brezillon
2017-12-14 15:16 ` [PATCH v2 3/7] docs: driver-api: Add I3C documentation Boris Brezillon
2017-12-14 15:16 ` [PATCH v2 4/7] i3c: Add sysfs ABI spec Boris Brezillon
2017-12-14 15:16 ` [PATCH v2 5/7] dt-bindings: i3c: Document core bindings Boris Brezillon
2017-12-14 16:24   ` Geert Uytterhoeven
2017-12-14 21:47   ` Peter Rosin
2017-12-16 17:20   ` Rob Herring
2017-12-16 18:35     ` Boris Brezillon
2017-12-20 18:06       ` Rob Herring
2017-12-21 10:41         ` Boris Brezillon
2017-12-26 18:29           ` Rob Herring
2018-01-07 14:14             ` Boris Brezillon
2018-01-22  8:47               ` Boris Brezillon
2017-12-14 15:16 ` [PATCH v2 6/7] i3c: master: Add driver for Cadence IP Boris Brezillon
2017-12-14 19:54   ` Randy Dunlap
2017-12-14 20:17     ` Boris Brezillon
2017-12-14 20:25       ` Randy Dunlap
2017-12-14 20:44         ` Boris Brezillon
2017-12-14 22:10           ` Randy Dunlap
2017-12-14 15:16 ` [PATCH v2 7/7] dt-bindings: i3c: Document Cadence I3C master bindings Boris Brezillon
2018-02-22 15:00 ` [PATCH v2 0/7] Add the I3C subsystem Vitor Soares

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).