linux

mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00

3100 lines

78 KiB

Raw Normal View History

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00














i3c: master: Enable runtime PM for master controller Enable runtime PM for i3c master node during master registration time. Sometimes i3c client device driver may want to control the PM of the parent (master) to perform the transactions and save the power in an efficient way by controlling the session. Hence device can call PM APIs by passing the parent node. Here, I3C target device when calls pm_runtime_get_sync(dev->parent) couldn't invoke master drivers runtime PM callback registered by the master driver because parent's PM status was disabled in the Master node. Also call pm_runtime_no_callbacks() and pm_suspend_ignore_children() for the master node to not have any callback addition and ignore the children to have runtime PM work just locally in the driver. This should be generic and common change for all i3c devices and should not have any other impact. With these changes, I3C client device works and able to invoke master driver registered runtime PM callbacks. Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> Link: https://lore.kernel.org/r/20240228093407.4038399-1-quic_msavaliy@quicinc.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-02-28 15:04:07 +05:30
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00







i3c: Allow OF-alias-based persistent bus numbering Parse the /aliases node to assign any fixed bus numbers, as is done with the i2c subsystem. Numbering for non-aliased busses will start after the highest fixed bus number. This allows an alias node such as: aliases { i3c0 = &bus_a, i3c4 = &bus_b, }; to set the numbering for a set of i3c controllers: /* fixed-numbered bus, assigned "i3c-0" / bus_a: i3c-master { }; / another fixed-numbered bus, assigned "i3c-4" / bus_b: i3c-master { }; / dynamic-numbered bus, likely assigned "i3c-5" */ bus_c: i3c-master { }; If no i3c device aliases are present, the numbering will stay as-is, starting from 0. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://lore.kernel.org/r/20230405094149.1513209-1-jk@codeconstruct.com.au Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-04-05 17:41:49 +08:00
i3c: Add support for bus enumeration & notification This allows other drivers to be notified when new i3c busses are attached, referring to a whole i3c bus as opposed to individual devices. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> 2023-10-13 12:06:24 +08:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00





































































i3c: fix i2c and i3c scl rate by bus mode Currently the I3C framework limits SCL frequency to FM speed when dealing with a mixed slow bus, even if all I2C devices are FM+ capable. The core was also not accounting for I3C speed limitations when operating in mixed slow mode and was erroneously using FM+ speed as the max I2C speed when operating in mixed fast mode. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <stable@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-06-19 20:36:31 +02:00





i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

























i3c: master: Use dev_to_i3cmaster() Since we have dev_to_i3cmaster() available, use it. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-08-16 15:08:25 +08:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00




















































































































i3c: Add a modalias sysfs attribute Create a modalias sysfs attribute for i3c devices. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Link: https://lore.kernel.org/linux-i3c/a90f64f830128cd12762153de7828b775574c156.1582796652.git.vitor.soares@synopsys.com 2020-02-27 12:31:07 +01:00




















i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00





i3c: Add a modalias sysfs attribute Create a modalias sysfs attribute for i3c devices. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Link: https://lore.kernel.org/linux-i3c/a90f64f830128cd12762153de7828b775574c156.1582796652.git.vitor.soares@synopsys.com 2020-02-27 12:31:07 +01:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00



driver core: make struct device_type.uevent() take a const * The uevent() callback in struct device_type should not be modifying the device that is passed into it, so mark it as a const * and propagate the function signature changes out into all relevant subsystems that use this callback. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Andreas Noever <andreas.noever@gmail.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Bard Liao <yung-chuan.liao@linux.intel.com> Cc: Chaitanya Kulkarni <kch@nvidia.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jens Axboe <axboe@kernel.dk> Cc: Jilin Yuan <yuanjilin@cdjrlc.com> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: Len Brown <lenb@kernel.org> Cc: Mark Gross <markgross@kernel.org> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org> Cc: Maximilian Luz <luzmaximilian@gmail.com> Cc: Michael Jamet <michael.jamet@intel.com> Cc: Ming Lei <ming.lei@redhat.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Sanyog Kale <sanyog.r.kale@intel.com> Cc: Sean Young <sean@mess.org> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Won Chung <wonchung@google.com> Cc: Yehezkel Bernat <YehezkelShB@gmail.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> # for Thunderbolt Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Wolfram Sang <wsa@kernel.org> Acked-by: Vinod Koul <vkoul@kernel.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230111113018.459199-6-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-01-11 12:30:07 +01:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
driver core: make struct device_type.uevent() take a const * The uevent() callback in struct device_type should not be modifying the device that is passed into it, so mark it as a const * and propagate the function signature changes out into all relevant subsystems that use this callback. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Andreas Noever <andreas.noever@gmail.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Bard Liao <yung-chuan.liao@linux.intel.com> Cc: Chaitanya Kulkarni <kch@nvidia.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jens Axboe <axboe@kernel.dk> Cc: Jilin Yuan <yuanjilin@cdjrlc.com> Cc: Jiri Slaby <jirislaby@kernel.org> Cc: Len Brown <lenb@kernel.org> Cc: Mark Gross <markgross@kernel.org> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org> Cc: Maximilian Luz <luzmaximilian@gmail.com> Cc: Michael Jamet <michael.jamet@intel.com> Cc: Ming Lei <ming.lei@redhat.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Sanyog Kale <sanyog.r.kale@intel.com> Cc: Sean Young <sean@mess.org> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Won Chung <wonchung@google.com> Cc: Yehezkel Bernat <YehezkelShB@gmail.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> # for Thunderbolt Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Wolfram Sang <wsa@kernel.org> Acked-by: Vinod Koul <vkoul@kernel.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230111113018.459199-6-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-01-11 12:30:07 +01:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00


i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock A deadlock may happen since the i3c_master_register() acquires &i3cbus->lock twice. See the log below. Use i3cdev->desc->info instead of calling i3c_device_info() to avoid acquiring the lock twice. v2: - Modified the title and commit message ============================================ WARNING: possible recursive locking detected 6.11.0-mainline -------------------------------------------- init/1 is trying to acquire lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_bus_normaluse_lock but task is already holding lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&i3cbus->lock); lock(&i3cbus->lock); * DEADLOCK * May be due to missing lock nesting notation 2 locks held by init/1: #0: fcffff809b6798f8 (&dev->mutex){....}-{3:3}, at: __driver_attach #1: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register stack backtrace: CPU: 6 UID: 0 PID: 1 Comm: init Call trace: dump_backtrace+0xfc/0x17c show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc0 dump_stack+0x18/0x24 print_deadlock_bug+0x388/0x390 __lock_acquire+0x18bc/0x32ec lock_acquire+0x134/0x2b0 down_read+0x50/0x19c i3c_bus_normaluse_lock+0x14/0x24 i3c_device_get_info+0x24/0x58 i3c_device_uevent+0x34/0xa4 dev_uevent+0x310/0x384 kobject_uevent_env+0x244/0x414 kobject_uevent+0x14/0x20 device_add+0x278/0x460 device_register+0x20/0x34 i3c_master_register_new_i3c_devs+0x78/0x154 i3c_master_register+0x6a0/0x6d4 mtk_i3c_master_probe+0x3b8/0x4d8 platform_probe+0xa0/0xe0 really_probe+0x114/0x454 __driver_probe_device+0xa0/0x15c driver_probe_device+0x3c/0x1ac __driver_attach+0xc4/0x1f0 bus_for_each_dev+0x104/0x160 driver_attach+0x24/0x34 bus_add_driver+0x14c/0x294 driver_register+0x68/0x104 __platform_driver_register+0x20/0x30 init_module+0x20/0xfe4 do_one_initcall+0x184/0x464 do_init_module+0x58/0x1ec load_module+0xefc/0x10c8 __arm64_sys_finit_module+0x238/0x33c invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x50/0xac el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac Signed-off-by: Defa Li <defa.li@mediatek.com> Link: https://lore.kernel.org/r/20241107132549.25439-1-defa.li@mediatek.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-11-07 21:25:39 +08:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00








i3c: Fix MODALIAS uevents file2alias uses %X formatters. Fix typos in the MODALIAS uevent to print the part and ext IDs in uppercase. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Link: https://lore.kernel.org/linux-i3c/9ac5f1f8413fbb0481de76b5e43f2f4e1b2dc49f.1582796652.git.vitor.soares@synopsys.com 2020-02-27 12:31:06 +01:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00







driver core: have match() callback in struct bus_type take a const * In the match() callback, the struct device_driver * should not be changed, so change the function callback to be a const . This is one step of many towards making the driver core safe to have struct device_driver in read-only memory. Because the match() callback is in all busses, all busses are modified to handle this properly. This does entail switching some container_of() calls to container_of_const() to properly handle the constant . For some busses, like PCI and USB and HV, the const * is cast away in the match callback as those busses do want to modify those structures at this point in time (they have a local lock in the driver structure.) That will have to be changed in the future if they wish to have their struct device * in read-only-memory. Cc: Rafael J. Wysocki <rafael@kernel.org> Reviewed-by: Alex Elder <elder@kernel.org> Acked-by: Sumit Garg <sumit.garg@linaro.org> Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2024-07-01 14:07:37 +02:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

driver core: have match() callback in struct bus_type take a const * In the match() callback, the struct device_driver * should not be changed, so change the function callback to be a const . This is one step of many towards making the driver core safe to have struct device_driver in read-only memory. Because the match() callback is in all busses, all busses are modified to handle this properly. This does entail switching some container_of() calls to container_of_const() to properly handle the constant . For some busses, like PCI and USB and HV, the const * is cast away in the match callback as those busses do want to modify those structures at this point in time (they have a local lock in the driver structure.) That will have to be changed in the future if they wish to have their struct device * in read-only-memory. Cc: Rafael J. Wysocki <rafael@kernel.org> Reviewed-by: Alex Elder <elder@kernel.org> Acked-by: Sumit Garg <sumit.garg@linaro.org> Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2024-07-01 14:07:37 +02:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00



















bus: Make remove callback return void The driver core ignores the return value of this callback because there is only little it can do when a device disappears. This is the final bit of a long lasting cleanup quest where several buses were converted to also return void from their remove callback. Additionally some resource leaks were fixed that were caused by drivers returning an error code in the expectation that the driver won't go away. With struct bus_type::remove returning void it's prevented that newly implemented buses return an ignored error code and so don't anticipate wrong expectations for driver authors. Reviewed-by: Tom Rix <trix@redhat.com> (For fpga) Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com> (For drivers/s390 and drivers/vfio) Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> (For ARM, Amba and related parts) Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Chen-Yu Tsai <wens@csie.org> (for sunxi-rsb) Acked-by: Pali Rohár <pali@kernel.org> Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org> (for media) Acked-by: Hans de Goede <hdegoede@redhat.com> (For drivers/platform) Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-By: Vinod Koul <vkoul@kernel.org> Acked-by: Juergen Gross <jgross@suse.com> (For xen) Acked-by: Lee Jones <lee.jones@linaro.org> (For mfd) Acked-by: Johannes Thumshirn <jth@kernel.org> (For mcb) Acked-by: Johan Hovold <johan@kernel.org> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> (For slimbus) Acked-by: Kirti Wankhede <kwankhede@nvidia.com> (For vfio) Acked-by: Maximilian Luz <luzmaximilian@gmail.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> (For ulpi and typec) Acked-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com> (For ipack) Acked-by: Geoff Levand <geoff@infradead.org> (For ps3) Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com> (For thunderbolt) Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> (For intel_th) Acked-by: Dominik Brodowski <linux@dominikbrodowski.net> (For pcmcia) Acked-by: Rafael J. Wysocki <rafael@kernel.org> (For ACPI) Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> (rpmsg and apr) Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> (For intel-ish-hid) Acked-by: Dan Williams <dan.j.williams@intel.com> (For CXL, DAX, and NVDIMM) Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> (For isa) Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (For firewire) Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> (For hid) Acked-by: Thorsten Scherer <t.scherer@eckelmann.de> (For siox) Acked-by: Sven Van Asbroeck <TheSven73@gmail.com> (For anybuss) Acked-by: Ulf Hansson <ulf.hansson@linaro.org> (For MMC) Acked-by: Wolfram Sang <wsa@kernel.org> # for I2C Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Finn Thain <fthain@linux-m68k.org> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20210713193522.1770306-6-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2021-07-13 21:35:22 +02:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00



i3c: Make remove callback return void The driver core ignores the return value of struct bus_type::remove() because there is only little that can be done. To simplify the quest to make this function return void, let struct i3c_driver::remove() return void, too. This makes it obvious that returning an error code is a bad idea and future driver authors cannot get that wrong. Up to now there are no drivers with a remove callback, so there is no need to adapt drivers. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210128091048.17006-2-u.kleine-koenig@pengutronix.de 2021-01-28 10:10:48 +01:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00



i3c: Make i3c_bus_type const Since commit d492cc2573a0 ("driver core: device.h: make struct bus_type a const *"), the driver core can properly handle constant struct bus_type, move the i3c_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240213-bus_cleanup-i3c-v1-1-403aea18f05a@marliere.net Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-02-13 11:37:31 -03:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00




i3c: master: Enhance i3c_bus_type visibility for device searching & event monitoring Improve the visibility of i3c_bus_type to facilitate searching for i3c devices attached to the i3c bus. Enable other drivers to use bus_register_notifier to monitor i3c bus device events. Signed-off-by: Bhoomik Gupta <bhoomik.gupta@nxp.com> Link: https://lore.kernel.org/r/20240708053835.3003986-1-bhoomik.gupta@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-07-08 11:08:35 +05:30
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

i3c: master: Extend address status bit to 4 and add I3C_ADDR_SLOT_EXT_DESIRED Extend the address status bit to 4 and introduce the I3C_ADDR_SLOT_EXT_DESIRED macro to indicate that a device prefers a specific address. This is generally set by the 'assigned-address' in the device tree source (dts) file. ┌────┬─────────────┬───┬─────────┬───┐ │S/Sr│ 7'h7E RnW=0 │ACK│ ENTDAA │ T ├────┐ └────┴─────────────┴───┴─────────┴───┘ │ ┌─────────────────────────────────────────┘ │ ┌──┬─────────────┬───┬─────────────────┬────────────────┬───┬─────────┐ └─►│Sr│7'h7E RnW=1 │ACK│48bit UID BCR DCR│Assign 7bit Addr│PAR│ ACK/NACK│ └──┴─────────────┴───┴─────────────────┴────────────────┴───┴─────────┘ Some master controllers (such as HCI) need to prepare the entire above transaction before sending it out to the I3C bus. This means that a 7-bit dynamic address needs to be allocated before knowing the target device's UID information. However, some I3C targets may request specific addresses (called as "init_dyn_addr"), which is typically specified by the DT-'s assigned-address property. Lower addresses having higher IBI priority. If it is available, i3c_bus_get_free_addr() preferably return a free address that is not in the list of desired addresses (called as "init_dyn_addr"). This allows the device with the "init_dyn_addr" to switch to its "init_dyn_addr" when it hot-joins the I3C bus. Otherwise, if the "init_dyn_addr" is already in use by another I3C device, the target device will not be able to switch to its desired address. If the previous step fails, fallback returning one of the remaining unassigned address, regardless of its state in the desired list. Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-2-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:07 -04:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: fix incorrect address slot lookup on 64-bit The address slot bitmap is an array of unsigned long's which are the same size as an int on 32-bit platforms but not 64-bit. Loading the bitmap into an int could result in the incorrect status being returned for a slot and slots being reported as the wrong status. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210922165600.179394-1-quic_jiles@quicinc.com 2021-09-22 17:56:00 +01:00
i3c: master: Replace hard code 2 with macro I3C_ADDR_SLOT_STATUS_BITS Replace the hardcoded value 2, which indicates 2 bits for I3C address status, with the predefined macro I3C_ADDR_SLOT_STATUS_BITS. Improve maintainability and extensibility of the code. Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-1-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:06 -04:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00






i3c: master: Extend address status bit to 4 and add I3C_ADDR_SLOT_EXT_DESIRED Extend the address status bit to 4 and introduce the I3C_ADDR_SLOT_EXT_DESIRED macro to indicate that a device prefers a specific address. This is generally set by the 'assigned-address' in the device tree source (dts) file. ┌────┬─────────────┬───┬─────────┬───┐ │S/Sr│ 7'h7E RnW=0 │ACK│ ENTDAA │ T ├────┐ └────┴─────────────┴───┴─────────┴───┘ │ ┌─────────────────────────────────────────┘ │ ┌──┬─────────────┬───┬─────────────────┬────────────────┬───┬─────────┐ └─►│Sr│7'h7E RnW=1 │ACK│48bit UID BCR DCR│Assign 7bit Addr│PAR│ ACK/NACK│ └──┴─────────────┴───┴─────────────────┴────────────────┴───┴─────────┘ Some master controllers (such as HCI) need to prepare the entire above transaction before sending it out to the I3C bus. This means that a 7-bit dynamic address needs to be allocated before knowing the target device's UID information. However, some I3C targets may request specific addresses (called as "init_dyn_addr"), which is typically specified by the DT-'s assigned-address property. Lower addresses having higher IBI priority. If it is available, i3c_bus_get_free_addr() preferably return a free address that is not in the list of desired addresses (called as "init_dyn_addr"). This allows the device with the "init_dyn_addr" to switch to its "init_dyn_addr" when it hot-joins the I3C bus. Otherwise, if the "init_dyn_addr" is already in use by another I3C device, the target device will not be able to switch to its desired address. If the previous step fails, fallback returning one of the remaining unassigned address, regardless of its state in the desired list. Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-2-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:07 -04:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

i3c: master: Extend address status bit to 4 and add I3C_ADDR_SLOT_EXT_DESIRED Extend the address status bit to 4 and introduce the I3C_ADDR_SLOT_EXT_DESIRED macro to indicate that a device prefers a specific address. This is generally set by the 'assigned-address' in the device tree source (dts) file. ┌────┬─────────────┬───┬─────────┬───┐ │S/Sr│ 7'h7E RnW=0 │ACK│ ENTDAA │ T ├────┐ └────┴─────────────┴───┴─────────┴───┘ │ ┌─────────────────────────────────────────┘ │ ┌──┬─────────────┬───┬─────────────────┬────────────────┬───┬─────────┐ └─►│Sr│7'h7E RnW=1 │ACK│48bit UID BCR DCR│Assign 7bit Addr│PAR│ ACK/NACK│ └──┴─────────────┴───┴─────────────────┴────────────────┴───┴─────────┘ Some master controllers (such as HCI) need to prepare the entire above transaction before sending it out to the I3C bus. This means that a 7-bit dynamic address needs to be allocated before knowing the target device's UID information. However, some I3C targets may request specific addresses (called as "init_dyn_addr"), which is typically specified by the DT-'s assigned-address property. Lower addresses having higher IBI priority. If it is available, i3c_bus_get_free_addr() preferably return a free address that is not in the list of desired addresses (called as "init_dyn_addr"). This allows the device with the "init_dyn_addr" to switch to its "init_dyn_addr" when it hot-joins the I3C bus. Otherwise, if the "init_dyn_addr" is already in use by another I3C device, the target device will not be able to switch to its desired address. If the previous step fails, fallback returning one of the remaining unassigned address, regardless of its state in the desired list. Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-2-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:07 -04:00







i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: master: Replace hard code 2 with macro I3C_ADDR_SLOT_STATUS_BITS Replace the hardcoded value 2, which indicates 2 bits for I3C address status, with the predefined macro I3C_ADDR_SLOT_STATUS_BITS. Improve maintainability and extensibility of the code. Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-1-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:06 -04:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00





i3c: master: Extend address status bit to 4 and add I3C_ADDR_SLOT_EXT_DESIRED Extend the address status bit to 4 and introduce the I3C_ADDR_SLOT_EXT_DESIRED macro to indicate that a device prefers a specific address. This is generally set by the 'assigned-address' in the device tree source (dts) file. ┌────┬─────────────┬───┬─────────┬───┐ │S/Sr│ 7'h7E RnW=0 │ACK│ ENTDAA │ T ├────┐ └────┴─────────────┴───┴─────────┴───┘ │ ┌─────────────────────────────────────────┘ │ ┌──┬─────────────┬───┬─────────────────┬────────────────┬───┬─────────┐ └─►│Sr│7'h7E RnW=1 │ACK│48bit UID BCR DCR│Assign 7bit Addr│PAR│ ACK/NACK│ └──┴─────────────┴───┴─────────────────┴────────────────┴───┴─────────┘ Some master controllers (such as HCI) need to prepare the entire above transaction before sending it out to the I3C bus. This means that a 7-bit dynamic address needs to be allocated before knowing the target device's UID information. However, some I3C targets may request specific addresses (called as "init_dyn_addr"), which is typically specified by the DT-'s assigned-address property. Lower addresses having higher IBI priority. If it is available, i3c_bus_get_free_addr() preferably return a free address that is not in the list of desired addresses (called as "init_dyn_addr"). This allows the device with the "init_dyn_addr" to switch to its "init_dyn_addr" when it hot-joins the I3C bus. Otherwise, if the "init_dyn_addr" is already in use by another I3C device, the target device will not be able to switch to its desired address. If the previous step fails, fallback returning one of the remaining unassigned address, regardless of its state in the desired list. Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-2-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:07 -04:00







i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00










i3c: master: Extend address status bit to 4 and add I3C_ADDR_SLOT_EXT_DESIRED Extend the address status bit to 4 and introduce the I3C_ADDR_SLOT_EXT_DESIRED macro to indicate that a device prefers a specific address. This is generally set by the 'assigned-address' in the device tree source (dts) file. ┌────┬─────────────┬───┬─────────┬───┐ │S/Sr│ 7'h7E RnW=0 │ACK│ ENTDAA │ T ├────┐ └────┴─────────────┴───┴─────────┴───┘ │ ┌─────────────────────────────────────────┘ │ ┌──┬─────────────┬───┬─────────────────┬────────────────┬───┬─────────┐ └─►│Sr│7'h7E RnW=1 │ACK│48bit UID BCR DCR│Assign 7bit Addr│PAR│ ACK/NACK│ └──┴─────────────┴───┴─────────────────┴────────────────┴───┴─────────┘ Some master controllers (such as HCI) need to prepare the entire above transaction before sending it out to the I3C bus. This means that a 7-bit dynamic address needs to be allocated before knowing the target device's UID information. However, some I3C targets may request specific addresses (called as "init_dyn_addr"), which is typically specified by the DT-'s assigned-address property. Lower addresses having higher IBI priority. If it is available, i3c_bus_get_free_addr() preferably return a free address that is not in the list of desired addresses (called as "init_dyn_addr"). This allows the device with the "init_dyn_addr" to switch to its "init_dyn_addr" when it hot-joins the I3C bus. Otherwise, if the "init_dyn_addr" is already in use by another I3C device, the target device will not be able to switch to its desired address. If the previous step fails, fallback returning one of the remaining unassigned address, regardless of its state in the desired list. Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-2-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:07 -04:00






















i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00





i3c: master: Extend address status bit to 4 and add I3C_ADDR_SLOT_EXT_DESIRED Extend the address status bit to 4 and introduce the I3C_ADDR_SLOT_EXT_DESIRED macro to indicate that a device prefers a specific address. This is generally set by the 'assigned-address' in the device tree source (dts) file. ┌────┬─────────────┬───┬─────────┬───┐ │S/Sr│ 7'h7E RnW=0 │ACK│ ENTDAA │ T ├────┐ └────┴─────────────┴───┴─────────┴───┘ │ ┌─────────────────────────────────────────┘ │ ┌──┬─────────────┬───┬─────────────────┬────────────────┬───┬─────────┐ └─►│Sr│7'h7E RnW=1 │ACK│48bit UID BCR DCR│Assign 7bit Addr│PAR│ ACK/NACK│ └──┴─────────────┴───┴─────────────────┴────────────────┴───┴─────────┘ Some master controllers (such as HCI) need to prepare the entire above transaction before sending it out to the I3C bus. This means that a 7-bit dynamic address needs to be allocated before knowing the target device's UID information. However, some I3C targets may request specific addresses (called as "init_dyn_addr"), which is typically specified by the DT-'s assigned-address property. Lower addresses having higher IBI priority. If it is available, i3c_bus_get_free_addr() preferably return a free address that is not in the list of desired addresses (called as "init_dyn_addr"). This allows the device with the "init_dyn_addr" to switch to its "init_dyn_addr" when it hot-joins the I3C bus. Otherwise, if the "init_dyn_addr" is already in use by another I3C device, the target device will not be able to switch to its desired address. If the previous step fails, fallback returning one of the remaining unassigned address, regardless of its state in the desired list. Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-2-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:07 -04:00








i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
































i3c: Allow OF-alias-based persistent bus numbering Parse the /aliases node to assign any fixed bus numbers, as is done with the i2c subsystem. Numbering for non-aliased busses will start after the highest fixed bus number. This allows an alias node such as: aliases { i3c0 = &bus_a, i3c4 = &bus_b, }; to set the numbering for a set of i3c controllers: /* fixed-numbered bus, assigned "i3c-0" / bus_a: i3c-master { }; / another fixed-numbered bus, assigned "i3c-4" / bus_b: i3c-master { }; / dynamic-numbered bus, likely assigned "i3c-5" */ bus_c: i3c-master { }; If no i3c device aliases are present, the numbering will stay as-is, starting from 0. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://lore.kernel.org/r/20230405094149.1513209-1-jk@codeconstruct.com.au Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-04-05 17:41:49 +08:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: Allow OF-alias-based persistent bus numbering Parse the /aliases node to assign any fixed bus numbers, as is done with the i2c subsystem. Numbering for non-aliased busses will start after the highest fixed bus number. This allows an alias node such as: aliases { i3c0 = &bus_a, i3c4 = &bus_b, }; to set the numbering for a set of i3c controllers: /* fixed-numbered bus, assigned "i3c-0" / bus_a: i3c-master { }; / another fixed-numbered bus, assigned "i3c-4" / bus_b: i3c-master { }; / dynamic-numbered bus, likely assigned "i3c-5" */ bus_c: i3c-master { }; If no i3c device aliases are present, the numbering will stay as-is, starting from 0. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://lore.kernel.org/r/20230405094149.1513209-1-jk@codeconstruct.com.au Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-04-05 17:41:49 +08:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00






i3c: Allow OF-alias-based persistent bus numbering Parse the /aliases node to assign any fixed bus numbers, as is done with the i2c subsystem. Numbering for non-aliased busses will start after the highest fixed bus number. This allows an alias node such as: aliases { i3c0 = &bus_a, i3c4 = &bus_b, }; to set the numbering for a set of i3c controllers: /* fixed-numbered bus, assigned "i3c-0" / bus_a: i3c-master { }; / another fixed-numbered bus, assigned "i3c-4" / bus_b: i3c-master { }; / dynamic-numbered bus, likely assigned "i3c-5" */ bus_c: i3c-master { }; If no i3c device aliases are present, the numbering will stay as-is, starting from 0. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://lore.kernel.org/r/20230405094149.1513209-1-jk@codeconstruct.com.au Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-04-05 17:41:49 +08:00


i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: Allow OF-alias-based persistent bus numbering Parse the /aliases node to assign any fixed bus numbers, as is done with the i2c subsystem. Numbering for non-aliased busses will start after the highest fixed bus number. This allows an alias node such as: aliases { i3c0 = &bus_a, i3c4 = &bus_b, }; to set the numbering for a set of i3c controllers: /* fixed-numbered bus, assigned "i3c-0" / bus_a: i3c-master { }; / another fixed-numbered bus, assigned "i3c-4" / bus_b: i3c-master { }; / dynamic-numbered bus, likely assigned "i3c-5" */ bus_c: i3c-master { }; If no i3c device aliases are present, the numbering will stay as-is, starting from 0. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://lore.kernel.org/r/20230405094149.1513209-1-jk@codeconstruct.com.au Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-04-05 17:41:49 +08:00








i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00









i3c: Add support for bus enumeration & notification This allows other drivers to be notified when new i3c busses are attached, referring to a whole i3c bus as opposed to individual devices. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> 2023-10-13 12:06:24 +08:00





























i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00


i3c: add mixed limited bus mode The i3c bus spec defines a bus configuration where i2c devices don't have a 50ns filter but support SCL running at SDR max rate (12.5MHz). This patch introduces the limited bus mode so that users can use a higher speed in presence of i2c devices index 1. Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <linux-kernel@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-06-19 20:36:32 +02:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00











ic3: off by one in mode_show() This should be >= ARRAY_SIZE() to avoid reading one element beyond the end of the array. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> 2018-11-23 10:15:05 +03:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00























































i3c: master: add enable(disable) hot join in sys entry Add hotjoin entry in sys file system allow user enable/disable hotjoin feature. Add (*enable(disable)_hotjoin)() to i3c_master_controller_ops. Add api i3c_master_enable(disable)_hotjoin(); Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20231201222532.2431484-2-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-12-01 17:25:27 -05:00

















































































i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00









i3c: master: add enable(disable) hot join in sys entry Add hotjoin entry in sys file system allow user enable/disable hotjoin feature. Add (*enable(disable)_hotjoin)() to i3c_master_controller_ops. Add api i3c_master_enable(disable)_hotjoin(); Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20231201222532.2431484-2-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-12-01 17:25:27 -05:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00





















i3c: master: make i3c_bus_set_mode static i3c_bus_set_mode function is only used in master.c. Make it static to avoid warning when compiling with W=1. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-12-04 11:56:30 +01:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: fix i2c and i3c scl rate by bus mode Currently the I3C framework limits SCL frequency to FM speed when dealing with a mixed slow bus, even if all I2C devices are FM+ capable. The core was also not accounting for I3C speed limitations when operating in mixed slow mode and was erroneously using FM+ speed as the max I2C speed when operating in mixed fast mode. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <stable@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-06-19 20:36:31 +02:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

i3c: fix i2c and i3c scl rate by bus mode Currently the I3C framework limits SCL frequency to FM speed when dealing with a mixed slow bus, even if all I2C devices are FM+ capable. The core was also not accounting for I3C speed limitations when operating in mixed slow mode and was erroneously using FM+ speed as the max I2C speed when operating in mixed fast mode. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <stable@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-06-19 20:36:31 +02:00





i3c: add mixed limited bus mode The i3c bus spec defines a bus configuration where i2c devices don't have a 50ns filter but support SCL running at SDR max rate (12.5MHz). This patch introduces the limited bus mode so that users can use a higher speed in presence of i2c devices index 1. Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <linux-kernel@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-06-19 20:36:32 +02:00
i3c: fix i2c and i3c scl rate by bus mode Currently the I3C framework limits SCL frequency to FM speed when dealing with a mixed slow bus, even if all I2C devices are FM+ capable. The core was also not accounting for I3C speed limitations when operating in mixed slow mode and was erroneously using FM+ speed as the max I2C speed when operating in mixed fast mode. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <stable@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-06-19 20:36:31 +02:00













i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

i3c: fix i2c and i3c scl rate by bus mode Currently the I3C framework limits SCL frequency to FM speed when dealing with a mixed slow bus, even if all I2C devices are FM+ capable. The core was also not accounting for I3C speed limitations when operating in mixed slow mode and was erroneously using FM+ speed as the max I2C speed when operating in mixed fast mode. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <stable@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-06-19 20:36:31 +02:00


i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00





























i3c: remove i2c board info from i2c_dev_desc I2C board info is only required during adapter setup so there is no requirement to keeping a pointer to it once running. To support dynamic device addition we can't rely on board info - user-space creation through sysfs won't have a boardinfo. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220117174816.1963463-2-quic_jiles@quicinc.com 2022-01-17 17:48:15 +00:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00







i3c: remove i2c board info from i2c_dev_desc I2C board info is only required during adapter setup so there is no requirement to keeping a pointer to it once running. To support dynamic device addition we can't rely on board info - user-space creation through sysfs won't have a boardinfo. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220117174816.1963463-2-quic_jiles@quicinc.com 2022-01-17 17:48:15 +00:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00








































































i3c: remove i2c board info from i2c_dev_desc I2C board info is only required during adapter setup so there is no requirement to keeping a pointer to it once running. To support dynamic device addition we can't rely on board info - user-space creation through sysfs won't have a boardinfo. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220117174816.1963463-2-quic_jiles@quicinc.com 2022-01-17 17:48:15 +00:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00






































































































































































































































i3c: master: Use struct_size() helper Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes, in particular in the context in which this code is being used. So, replace the following form: sizeof(defslvs) + ((ndevs - 1) sizeof(struct i3c_ccc_dev_desc)) with: struct_size(defslvs, slaves, ndevs - 1) This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-05-31 12:35:32 -05:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00










i3c: add addr and lvr to i2c_dev_desc structure I need to store address and lvr value for I2C devices without static definition in DT. This allows secondary master to transmit DEFSLVS command properly. Main changes between v4 and v5: - Change in defslvs to use addr and lvr from i2c_dev_desc structure - Change in CDNS and DW drivers to use addr and lvr from i2c_dev_desc structure Signed-off-by: Przemyslaw Gaj <pgaj@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-06-22 21:54:59 +01:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00



















































































i3c master: GETMRL's 3rd byte is optional even with BCR_IBI_PAYLOAD According to the I3C spec v1.1 document, GETMRL's payload is 2 bytes, with an optional 3rd byte if the IBI private payload is larger than 1 byte. The whole GETMRL may also be optional so max_ibi_len already defaults to 1 if BCR_IBI_PAYLOAD prior to the i3c_master_getmrl_locked() call. Signed-off-by: Nicolas Pitre <npitre@baylibre.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/nycvar.YSQ.7.76.2004151623060.2671@knanqh.ubzr 2020-04-15 16:30:01 -04:00







i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00


























i3c: master: fix a memory leak bug In i3c_master_getmwl_locked(), the buffer used for the dest payload data is allocated using kzalloc() in i3c_ccc_cmd_dest_init(). Later on, the length of the dest payload data is checked against 'sizeof(*mwl)'. If they are not equal, -EIO is returned to indicate the error. However, the allocated buffer is not deallocated on this path, leading to a memory leak. To fix the above issue, free the buffer before returning the error. Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-08-11 13:33:06 -05:00



i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00























i3c: Add fallback method for GETMXDS CCC Some I3C hardware will report error when an incorrect length is received from device. GETMXDS CCC are available in 2 formats: without turnaround time (format 1) and with turnaround time (format 2). There is no mechanics to determine which format is supported by device. So in case sending GETMXDS CCC format 2 resulted in a failure, try sending GETMXDS CCC format 1 instead. Signed-off-by: Joshua Yeong <joshua.yeong@starfivetech.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20231114085525.6271-2-joshua.yeong@starfivetech.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-11-14 16:55:25 +08:00




i3c: master: Fix build error Fix build error caused by commit 2aac0bf4ebc8 ("i3c: Add fallback method for GETMXDS CCC") which incorrectly access the "struct i3c_ccc_cmd_dest dest" as pointer. drivers/i3c/master.c: In function ‘i3c_master_getmxds_locked’: drivers/i3c/master.c:1140:21: error: invalid type argument of ‘->’ (have ‘struct i3c_ccc_cmd_dest’) 1140 \| dest->payload.len -= 3; \| ^~ Fixes: 2aac0bf4ebc8 ("i3c: Add fallback method for GETMXDS CCC") Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20231117110924.634280-1-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-11-17 13:09:24 +02:00
i3c: Add fallback method for GETMXDS CCC Some I3C hardware will report error when an incorrect length is received from device. GETMXDS CCC are available in 2 formats: without turnaround time (format 1) and with turnaround time (format 2). There is no mechanics to determine which format is supported by device. So in case sending GETMXDS CCC format 2 resulted in a failure, try sending GETMXDS CCC format 1 instead. Signed-off-by: Joshua Yeong <joshua.yeong@starfivetech.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20231114085525.6271-2-joshua.yeong@starfivetech.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-11-14 16:55:25 +08:00



i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00































































































































































































i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs() if (dev->boardinfo && dev->boardinfo->init_dyn_addr) ^^^ here check "init_dyn_addr" i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) ^^^^ free "dyn_addr" Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr". Cc: stable@kernel.org Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241001162608.224039-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-01 12:26:08 -04:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00













i3c: master: Fix SETDASA process When a I3C DT node has a static_addr and an init_dyn_addr,the init_dyn_addr is reserved in i3c_master_bus_init() and then the static_addr is reserved in i3c_master_early_i3c_dev_add(). But if the dynamic address is same as static then above procedure would fail. Add a check to pass i3c_bus_get_addr_slot_status() when static and dynamic address are equal. Signed-off-by: Aniket <aniketmaurya@google.com> Link: https://lore.kernel.org/r/20230822051938.2852567-1-aniketmaurya@google.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-08-22 05:19:38 +00:00




i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00






































































i3c: master: Fix dynamic address leak when 'assigned-address' is present If the DTS contains 'assigned-address', a dynamic address leak occurs during hotjoin events. Assume a device have assigned-address 0xb. - Device issue Hotjoin - Call i3c_master_do_daa() - Call driver xxx_do_daa() - Call i3c_master_get_free_addr() to get dynamic address 0x9 - i3c_master_add_i3c_dev_locked(0x9) - expected_dyn_addr = newdev->boardinfo->init_dyn_addr (0xb); - i3c_master_reattach_i3c_dev(newdev(0xb), old_dyn_addr(0x9)); - if (dev->info.dyn_addr != old_dyn_addr && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0xb != 0x9 -> TRUE (!dev->boardinfo \|\| ^^^^^^^^^^^^^^^ -> FALSE dev->info.dyn_addr != dev->boardinfo->init_dyn_addr)) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0xb != 0xb -> FALSE ... i3c_bus_set_addr_slot_status(&master->bus, old_dyn_addr, I3C_ADDR_SLOT_FREE); ^^^ This will be skipped. So old_dyn_addr never free } - i3c_master_get_free_addr() will return increased sequence number. Remove dev->info.dyn_addr != dev->boardinfo->init_dyn_addr condition check. dev->info.dyn_addr should be checked before calling this function because i3c_master_setnewda_locked() has already been called and the target device has already accepted dyn_addr. It is too late to check if dyn_addr is free in i3c_master_reattach_i3c_dev(). Add check to ensure expected_dyn_addr is free before i3c_master_setnewda_locked(). Fixes: cc3a392d69b6 ("i3c: master: fix for SETDASA and DAA process") Cc: stable@kernel.org Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-3-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:08 -04:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00


i3c: master: Free the old_dyn_addr when reattach. This patch is used to free the old_dyn_addr when the caller want to reattach the device to the different dynamic address. If the old_dyn_addr is 0 the function will treat it as no old_dyn_addr is reserved on the bus. Without the patch, when the driver reattach the i3c device after setnewda the old_dyn_addr will be permanently occupied. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20220926105145.8145-1-billy_tsai@aspeedtech.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2022-09-26 18:51:44 +08:00


i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00


















































i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00

i3c: transfer pid from boardinfo to device info I3C device PID could be defined in device tree and stored in i3c_dev_boardinfo. It should be passed to i3c_device_info when allocating a i3c_dev_desc. Rational behind this change is: when users decide to use SETDASA to assign a dynamic address with exactly the original static address, in step of i3c_master_reattach_i3c_dev, this address is checked to be taken. Then device information retrieving step is skipped. As a result, though the i3c device is registered correctly, its device driver could not be probed. Tested: Tested with a I3C device. If assigned-address is set to be the device's static address, without this change, its device driver could not probed. And with this change, its driver is probed successfully. Signed-off-by: Jack Chen <zenghuchen@google.com> Link: https://lore.kernel.org/r/20230105212952.56321-1-zenghuchen@google.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-01-05 16:29:52 -05:00
i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00


i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00


i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00






i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00


i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00


i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00






i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00































i3c: Fix potential refcount leak in i3c_master_register_new_i3c_devs put_device() needs to be called on failure of device_register() to give up the reference initialized in it to avoid refcount leak. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Link: https://lore.kernel.org/r/20230921082410.25548-1-dinghao.liu@zju.edu.cn Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-09-21 16:24:10 +08:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

i3c: Fix potential refcount leak in i3c_master_register_new_i3c_devs put_device() needs to be called on failure of device_register() to give up the reference initialized in it to avoid refcount leak. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Link: https://lore.kernel.org/r/20230921082410.25548-1-dinghao.liu@zju.edu.cn Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-09-21 16:24:10 +08:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00





















































































































i3c: add addr and lvr to i2c_dev_desc structure I need to store address and lvr value for I2C devices without static definition in DT. This allows secondary master to transmit DEFSLVS command properly. Main changes between v4 and v5: - Change in defslvs to use addr and lvr from i2c_dev_desc structure - Change in CDNS and DW drivers to use addr and lvr from i2c_dev_desc structure Signed-off-by: Przemyslaw Gaj <pgaj@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-06-22 21:54:59 +01:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00










i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00










i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00



i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00































i3c: remove i2c board info from i2c_dev_desc I2C board info is only required during adapter setup so there is no requirement to keeping a pointer to it once running. To support dynamic device addition we can't rely on board info - user-space creation through sysfs won't have a boardinfo. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220117174816.1963463-2-quic_jiles@quicinc.com 2022-01-17 17:48:15 +00:00


i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00






























i3c: master: support to adjust first broadcast address speed According to I3C spec 6.2 Timing Specification, the Open Drain High Period of SCL Clock timing for first broadcast address should be adjusted to 200ns at least. I3C device working as i2c device will see the broadcast to close its Spike Filter then change to work at I3C mode. After that I3C open drain SCL high level should be adjusted back. Signed-off-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20240910051626.4052552-1-carlos.song@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-09-10 13:16:25 +08:00





i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00







i3c: master: support to adjust first broadcast address speed According to I3C spec 6.2 Timing Specification, the Open Drain High Period of SCL Clock timing for first broadcast address should be adjusted to 200ns at least. I3C device working as i2c device will see the broadcast to close its Spike Filter then change to work at I3C mode. After that I3C open drain SCL high level should be adjusted back. Signed-off-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20240910051626.4052552-1-carlos.song@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-09-10 13:16:25 +08:00
i3c: master: Fix missing 'ret' assignment in set_speed() Fix a probe failure in the i3c master driver that occurs when no i3c devices are connected to the bus. The issue arises in `i3c_master_bus_init()` where the `ret` value is not updated after calling `master->ops->set_speed()`. If no devices are present, `ret` remains set to `I3C_ERROR_M2`, causing the code to incorrectly proceed to `err_bus_cleanup`. Cc: stable@vger.kernel.org Fixes: aef79e189ba2 ("i3c: master: support to adjust first broadcast address speed") Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20250108225533.915334-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2025-01-08 17:55:33 -05:00
i3c: master: support to adjust first broadcast address speed According to I3C spec 6.2 Timing Specification, the Open Drain High Period of SCL Clock timing for first broadcast address should be adjusted to 200ns at least. I3C device working as i2c device will see the broadcast to close its Spike Filter then change to work at I3C mode. After that I3C open drain SCL high level should be adjusted back. Signed-off-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20240910051626.4052552-1-carlos.song@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-09-10 13:16:25 +08:00



i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00







i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00




i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00















i3c: master: Fix dynamic address leak when 'assigned-address' is present If the DTS contains 'assigned-address', a dynamic address leak occurs during hotjoin events. Assume a device have assigned-address 0xb. - Device issue Hotjoin - Call i3c_master_do_daa() - Call driver xxx_do_daa() - Call i3c_master_get_free_addr() to get dynamic address 0x9 - i3c_master_add_i3c_dev_locked(0x9) - expected_dyn_addr = newdev->boardinfo->init_dyn_addr (0xb); - i3c_master_reattach_i3c_dev(newdev(0xb), old_dyn_addr(0x9)); - if (dev->info.dyn_addr != old_dyn_addr && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0xb != 0x9 -> TRUE (!dev->boardinfo \|\| ^^^^^^^^^^^^^^^ -> FALSE dev->info.dyn_addr != dev->boardinfo->init_dyn_addr)) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0xb != 0xb -> FALSE ... i3c_bus_set_addr_slot_status(&master->bus, old_dyn_addr, I3C_ADDR_SLOT_FREE); ^^^ This will be skipped. So old_dyn_addr never free } - i3c_master_get_free_addr() will return increased sequence number. Remove dev->info.dyn_addr != dev->boardinfo->init_dyn_addr condition check. dev->info.dyn_addr should be checked before calling this function because i3c_master_setnewda_locked() has already been called and the target device has already accepted dyn_addr. It is too late to check if dyn_addr is free in i3c_master_reattach_i3c_dev(). Add check to ensure expected_dyn_addr is free before i3c_master_setnewda_locked(). Fixes: cc3a392d69b6 ("i3c: master: fix for SETDASA and DAA process") Cc: stable@kernel.org Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-3-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:08 -04:00
i3c: master: Extend address status bit to 4 and add I3C_ADDR_SLOT_EXT_DESIRED Extend the address status bit to 4 and introduce the I3C_ADDR_SLOT_EXT_DESIRED macro to indicate that a device prefers a specific address. This is generally set by the 'assigned-address' in the device tree source (dts) file. ┌────┬─────────────┬───┬─────────┬───┐ │S/Sr│ 7'h7E RnW=0 │ACK│ ENTDAA │ T ├────┐ └────┴─────────────┴───┴─────────┴───┘ │ ┌─────────────────────────────────────────┘ │ ┌──┬─────────────┬───┬─────────────────┬────────────────┬───┬─────────┐ └─►│Sr│7'h7E RnW=1 │ACK│48bit UID BCR DCR│Assign 7bit Addr│PAR│ ACK/NACK│ └──┴─────────────┴───┴─────────────────┴────────────────┴───┴─────────┘ Some master controllers (such as HCI) need to prepare the entire above transaction before sending it out to the I3C bus. This means that a 7-bit dynamic address needs to be allocated before knowing the target device's UID information. However, some I3C targets may request specific addresses (called as "init_dyn_addr"), which is typically specified by the DT-'s assigned-address property. Lower addresses having higher IBI priority. If it is available, i3c_bus_get_free_addr() preferably return a free address that is not in the list of desired addresses (called as "init_dyn_addr"). This allows the device with the "init_dyn_addr" to switch to its "init_dyn_addr" when it hot-joins the I3C bus. Otherwise, if the "init_dyn_addr" is already in use by another I3C device, the target device will not be able to switch to its desired address. If the previous step fails, fallback returning one of the remaining unassigned address, regardless of its state in the desired list. Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-2-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:07 -04:00

i3c: master: Fix dynamic address leak when 'assigned-address' is present If the DTS contains 'assigned-address', a dynamic address leak occurs during hotjoin events. Assume a device have assigned-address 0xb. - Device issue Hotjoin - Call i3c_master_do_daa() - Call driver xxx_do_daa() - Call i3c_master_get_free_addr() to get dynamic address 0x9 - i3c_master_add_i3c_dev_locked(0x9) - expected_dyn_addr = newdev->boardinfo->init_dyn_addr (0xb); - i3c_master_reattach_i3c_dev(newdev(0xb), old_dyn_addr(0x9)); - if (dev->info.dyn_addr != old_dyn_addr && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0xb != 0x9 -> TRUE (!dev->boardinfo \|\| ^^^^^^^^^^^^^^^ -> FALSE dev->info.dyn_addr != dev->boardinfo->init_dyn_addr)) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0xb != 0xb -> FALSE ... i3c_bus_set_addr_slot_status(&master->bus, old_dyn_addr, I3C_ADDR_SLOT_FREE); ^^^ This will be skipped. So old_dyn_addr never free } - i3c_master_get_free_addr() will return increased sequence number. Remove dev->info.dyn_addr != dev->boardinfo->init_dyn_addr condition check. dev->info.dyn_addr should be checked before calling this function because i3c_master_setnewda_locked() has already been called and the target device has already accepted dyn_addr. It is too late to check if dyn_addr is free in i3c_master_reattach_i3c_dev(). Add check to ensure expected_dyn_addr is free before i3c_master_setnewda_locked(). Fixes: cc3a392d69b6 ("i3c: master: fix for SETDASA and DAA process") Cc: stable@kernel.org Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-3-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:08 -04:00
i3c: master: Extend address status bit to 4 and add I3C_ADDR_SLOT_EXT_DESIRED Extend the address status bit to 4 and introduce the I3C_ADDR_SLOT_EXT_DESIRED macro to indicate that a device prefers a specific address. This is generally set by the 'assigned-address' in the device tree source (dts) file. ┌────┬─────────────┬───┬─────────┬───┐ │S/Sr│ 7'h7E RnW=0 │ACK│ ENTDAA │ T ├────┐ └────┴─────────────┴───┴─────────┴───┘ │ ┌─────────────────────────────────────────┘ │ ┌──┬─────────────┬───┬─────────────────┬────────────────┬───┬─────────┐ └─►│Sr│7'h7E RnW=1 │ACK│48bit UID BCR DCR│Assign 7bit Addr│PAR│ ACK/NACK│ └──┴─────────────┴───┴─────────────────┴────────────────┴───┴─────────┘ Some master controllers (such as HCI) need to prepare the entire above transaction before sending it out to the I3C bus. This means that a 7-bit dynamic address needs to be allocated before knowing the target device's UID information. However, some I3C targets may request specific addresses (called as "init_dyn_addr"), which is typically specified by the DT-'s assigned-address property. Lower addresses having higher IBI priority. If it is available, i3c_bus_get_free_addr() preferably return a free address that is not in the list of desired addresses (called as "init_dyn_addr"). This allows the device with the "init_dyn_addr" to switch to its "init_dyn_addr" when it hot-joins the I3C bus. Otherwise, if the "init_dyn_addr" is already in use by another I3C device, the target device will not be able to switch to its desired address. If the previous step fails, fallback returning one of the remaining unassigned address, regardless of its state in the desired list. Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-2-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:07 -04:00
i3c: master: fix for SETDASA and DAA process This patch fix following issue. Controller slots blocked for devices with static_addr but no init_dyn_addr may limit the number of I3C devices on the bus which gets dynamic address in DAA. So instead of attaching all the devices with static_addr, now we only attach the devices which successfully complete SETDASA. For remaining devices with init_dyn_addr, i3c_master_add_i3c_dev_locked() will try to set requested dynamic address after DAA. Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1598337109-14770-1-git-send-email-pthombar@cadence.com 2020-08-25 08:31:49 +02:00











i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00



























i3c: master add i3c_master_attach_boardinfo to preserve boardinfo Boardinfo was lost if I3C object for devices with boardinfo available are not created or not added to the I3C device list because of some failure e.g. SETDASA failed, retrieve info failed etc This patch adds i3c_master_attach_boardinfo which scan boardinfo list in the master object and 'attach' it to the I3C device object. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1590053542-389-1-git-send-email-pthombar@cadence.com 2020-05-21 11:32:22 +02:00














i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00


i3c: master: use i3c_dev_get_master() Since we have i3c_dev_get_master() available, use it. Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-09-05 13:06:52 +02:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00











































i3c: fix an error code in i3c_master_add_i3c_dev_locked() We should return "ret" as-is. The "newdev" variable is a valid pointer. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> 2018-11-23 10:14:42 +03:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00



i3c: fix missing detach if failed to retrieve i3c dev If we failed to retrieve the i3c dev, we should detach the i3c dev I.E i3c_master_detach_i3c_dev(). Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: Boris Brezillon <bbrezillon@kernel.org> 2019-01-25 07:40:32 +00:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: master add i3c_master_attach_boardinfo to preserve boardinfo Boardinfo was lost if I3C object for devices with boardinfo available are not created or not added to the I3C device list because of some failure e.g. SETDASA failed, retrieve info failed etc This patch adds i3c_master_attach_boardinfo which scan boardinfo list in the master object and 'attach' it to the I3C device object. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/1590053542-389-1-git-send-email-pthombar@cadence.com 2020-05-21 11:32:22 +02:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

















i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin When a new device hotjoins, a new dynamic address is assigned. i3c_master_add_i3c_dev_locked() identifies that the device was previously attached to the bus and locates the olddev. i3c_master_add_i3c_dev_locked() { ... olddev = i3c_master_search_i3c_dev_duplicate(newdev); ... if (olddev) { ... i3c_dev_disable_ibi_locked(olddev); ^^^^^^ The olddev should not receive any commands on the i3c bus as it does not exist and has been assigned a new address. This will result in NACK or timeout. So remove it. } i3c_dev_free_ibi_locked(olddev); ^^^^^^^^ This function internally calls i3c_dev_disable_ibi_locked() function causing to send DISEC command with old Address. The olddev should not receive any commands on the i3c bus as it does not exist and has been assigned a new address. This will result in NACK or timeout. So, update the olddev->ibi->enabled flag to false to avoid DISEC with OldAddr. } Include part of Ravindra Yashvant Shinde's work: https://lore.kernel.org/linux-i3c/20240820151917.3904956-1-ravindra.yashvant.shinde@nxp.com/T/#u Fixes: 317bacf960a4 ("i3c: master: add enable(disable) hot join in sys entry") Co-developed-by: Ravindra Yashvant Shinde <ravindra.yashvant.shinde@nxp.com> Signed-off-by: Ravindra Yashvant Shinde <ravindra.yashvant.shinde@nxp.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241001162232.223724-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-01 12:22:32 -04:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin When a new device hotjoins, a new dynamic address is assigned. i3c_master_add_i3c_dev_locked() identifies that the device was previously attached to the bus and locates the olddev. i3c_master_add_i3c_dev_locked() { ... olddev = i3c_master_search_i3c_dev_duplicate(newdev); ... if (olddev) { ... i3c_dev_disable_ibi_locked(olddev); ^^^^^^ The olddev should not receive any commands on the i3c bus as it does not exist and has been assigned a new address. This will result in NACK or timeout. So remove it. } i3c_dev_free_ibi_locked(olddev); ^^^^^^^^ This function internally calls i3c_dev_disable_ibi_locked() function causing to send DISEC command with old Address. The olddev should not receive any commands on the i3c bus as it does not exist and has been assigned a new address. This will result in NACK or timeout. So, update the olddev->ibi->enabled flag to false to avoid DISEC with OldAddr. } Include part of Ravindra Yashvant Shinde's work: https://lore.kernel.org/linux-i3c/20240820151917.3904956-1-ravindra.yashvant.shinde@nxp.com/T/#u Fixes: 317bacf960a4 ("i3c: master: add enable(disable) hot join in sys entry") Co-developed-by: Ravindra Yashvant Shinde <ravindra.yashvant.shinde@nxp.com> Signed-off-by: Ravindra Yashvant Shinde <ravindra.yashvant.shinde@nxp.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241001162232.223724-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-01 12:22:32 -04:00







i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00


























i3c: master: Fix dynamic address leak when 'assigned-address' is present If the DTS contains 'assigned-address', a dynamic address leak occurs during hotjoin events. Assume a device have assigned-address 0xb. - Device issue Hotjoin - Call i3c_master_do_daa() - Call driver xxx_do_daa() - Call i3c_master_get_free_addr() to get dynamic address 0x9 - i3c_master_add_i3c_dev_locked(0x9) - expected_dyn_addr = newdev->boardinfo->init_dyn_addr (0xb); - i3c_master_reattach_i3c_dev(newdev(0xb), old_dyn_addr(0x9)); - if (dev->info.dyn_addr != old_dyn_addr && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0xb != 0x9 -> TRUE (!dev->boardinfo \|\| ^^^^^^^^^^^^^^^ -> FALSE dev->info.dyn_addr != dev->boardinfo->init_dyn_addr)) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0xb != 0xb -> FALSE ... i3c_bus_set_addr_slot_status(&master->bus, old_dyn_addr, I3C_ADDR_SLOT_FREE); ^^^ This will be skipped. So old_dyn_addr never free } - i3c_master_get_free_addr() will return increased sequence number. Remove dev->info.dyn_addr != dev->boardinfo->init_dyn_addr condition check. dev->info.dyn_addr should be checked before calling this function because i3c_master_setnewda_locked() has already been called and the target device has already accepted dyn_addr. It is too late to check if dyn_addr is free in i3c_master_reattach_i3c_dev(). Add check to ensure expected_dyn_addr is free before i3c_master_setnewda_locked(). Fixes: cc3a392d69b6 ("i3c: master: fix for SETDASA and DAA process") Cc: stable@kernel.org Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-3-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-10-21 11:45:08 -04:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00










































































i3c: Drop support for I2C 10 bit addresing This patch drops support for I2C devices with 10 bit addressing. When I2C device with 10 bit address is defined in DT, I3C master registration fails. Address space for I2C devices has been reduced and ->i2c_funcs() hook has been removed. Because this patch series dropped support for 10 bit I2C devices, support is also dropped in Cadence I3C master driver and Synopsys DesignWare I3C master driver. Signed-off-by: Przemyslaw Gaj <pgaj@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-04-16 09:36:14 +01:00





i3c: master: no need to iterate master device twice We already have the master device in a variable, reuse it. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Vitor Soares <vitor.soares@synopsys.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-i3c/20200214145853.24762-1-wsa+renesas@sang-engineering.com 2020-02-14 15:58:53 +01:00
i3c: Drop support for I2C 10 bit addresing This patch drops support for I2C devices with 10 bit addressing. When I2C device with 10 bit address is defined in DT, I3C master registration fails. Address space for I2C devices has been reduced and ->i2c_funcs() hook has been removed. Because this patch series dropped support for 10 bit I2C devices, support is also dropped in Cadence I3C master driver and Synopsys DesignWare I3C master driver. Signed-off-by: Przemyslaw Gaj <pgaj@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-04-16 09:36:14 +01:00


i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00













































i3c: Fix the verification of random PID The validation of random PID should be done by checking the boardinfo->pid instead of info.pid which is empty. Doing the change the info struture declaration is no longer necessary. Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <stable@vger.kernel.org> Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-04-09 18:59:59 +02:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00














































i3c: master: Add of_node_put() before return Each iteration of for_each_available_childe_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Add an of_node_put before the return. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-07-23 16:07:25 +05:30

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: master: Add of_node_put() before return Each iteration of for_each_available_childe_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Add an of_node_put before the return. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-07-23 16:07:25 +05:30
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00















































i3c: Drop support for I2C 10 bit addresing This patch drops support for I2C devices with 10 bit addressing. When I2C device with 10 bit address is defined in DT, I3C master registration fails. Address space for I2C devices has been reduced and ->i2c_funcs() hook has been removed. Because this patch series dropped support for 10 bit I2C devices, support is also dropped in Cadence I3C master driver and Synopsys DesignWare I3C master driver. Signed-off-by: Przemyslaw Gaj <pgaj@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-04-16 09:36:14 +01:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: Drop support for I2C 10 bit addresing This patch drops support for I2C devices with 10 bit addressing. When I2C device with 10 bit address is defined in DT, I3C master registration fails. Address space for I2C devices has been reduced and ->i2c_funcs() hook has been removed. Because this patch series dropped support for 10 bit I2C devices, support is also dropped in Cadence I3C master driver and Synopsys DesignWare I3C master driver. Signed-off-by: Przemyslaw Gaj <pgaj@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-04-16 09:36:14 +01:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

i3c: support dynamically added i2c devices I2C devices can be added to the system dynamically through several sources other than static board info including device tree overlays and sysfs i2c new_device. Add an I2C bus notifier to attach the clients at runtime if they were not defined in the board info. For DT devices find the LVR in the reg property, for user-space new_device additions we synthesize a conservative setting of no spike filters and fast mode only. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220117174816.1963463-3-quic_jiles@quicinc.com 2022-01-17 17:48:16 +00:00








































































i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

i3c: Drop support for I2C 10 bit addresing This patch drops support for I2C devices with 10 bit addressing. When I2C device with 10 bit address is defined in DT, I3C master registration fails. Address space for I2C devices has been reduced and ->i2c_funcs() hook has been removed. Because this patch series dropped support for 10 bit I2C devices, support is also dropped in Cadence I3C master driver and Synopsys DesignWare I3C master driver. Signed-off-by: Przemyslaw Gaj <pgaj@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-04-16 09:36:14 +01:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

i3c: support dynamically added i2c devices I2C devices can be added to the system dynamically through several sources other than static board info including device tree overlays and sysfs i2c new_device. Add an I2C bus notifier to attach the clients at runtime if they were not defined in the board info. For DT devices find the LVR in the reg property, for user-space new_device additions we synthesize a conservative setting of no spike filters and fast mode only. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220117174816.1963463-3-quic_jiles@quicinc.com 2022-01-17 17:48:16 +00:00





































i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00



i3c: remove i2c board info from i2c_dev_desc I2C board info is only required during adapter setup so there is no requirement to keeping a pointer to it once running. To support dynamic device addition we can't rely on board info - user-space creation through sysfs won't have a boardinfo. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220117174816.1963463-2-quic_jiles@quicinc.com 2022-01-17 17:48:15 +00:00
i3c: master: Improve initialization of numbered I2C adapters Add logic to initialize I2C adapters with a specific ID if available, improving device identification and configuration. For mixed buses, in addition to the i3c alias, an i2c alias can be added to assign a fixed bus number to the i2c adapter. This allows an alias node such as: aliases { i2c2 = &mixed_bus_a, i3c2 = &mixed_bus_a, i3c4 = &mixed_bus_b, }; /* assigned "i3c-2" and "i2c-2" / mixed_bus_a: i3c-master { }; If there is no i2c alias for a mixed bus, the i2c adapter numbers will remain as is and will be assigned starting after the highest fixed bus number. / assigned "i3c-4" and likely assigned "i2c-3" */ mixed_bus_b: i3c-master { }; Signed-off-by: Defa Li <defa.li@mediatek.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241212091818.8591-1-defa.li@mediatek.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-12-12 17:17:53 +08:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00



i3c: replace deprecated strncpy `strncpy` is deprecated for use on NUL-terminated destination strings [1]. We should prefer more robust and less ambiguous string interfaces. We expect adap->name to be NUL-terminated based on i2c_adapter name use: \| dev_dbg(&adap->dev, "adapter [%s] registered\n", adap->name); NUL-padding does not seem to be required as `master` is zero-allocated and `i3c_master_to_i2c_adapter` simply returns a field from within `master`: \| master = devm_kzalloc(dev, sizeof(master), GFP_KERNEL); ... \| struct i2c_adapter adap = i3c_master_to_i2c_adapter(master); ... \| static struct i2c_adapter * \| i3c_master_to_i2c_adapter(struct i3c_master_controller *master) \| { \| return &master->i2c; \| } This means that `adap->name` should already be filled with NUL-bytes. Considering the above, a suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230921-strncpy-drivers-i3c-master-c-v1-1-9fdb8d8169e1@google.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-09-21 03:51:04 +00:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00




i3c: master: Improve initialization of numbered I2C adapters Add logic to initialize I2C adapters with a specific ID if available, improving device identification and configuration. For mixed buses, in addition to the i3c alias, an i2c alias can be added to assign a fixed bus number to the i2c adapter. This allows an alias node such as: aliases { i2c2 = &mixed_bus_a, i3c2 = &mixed_bus_a, i3c4 = &mixed_bus_b, }; /* assigned "i3c-2" and "i2c-2" / mixed_bus_a: i3c-master { }; If there is no i2c alias for a mixed bus, the i2c adapter numbers will remain as is and will be assigned starting after the highest fixed bus number. / assigned "i3c-4" and likely assigned "i2c-3" */ mixed_bus_b: i3c-master { }; Signed-off-by: Defa Li <defa.li@mediatek.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241212091818.8591-1-defa.li@mediatek.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-12-12 17:17:53 +08:00








i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00






i3c: fix uninitialized variable use in i2c setup Commit 31b9887c7258 ("i3c: remove i2c board info from i2c_dev_desc") removed the boardinfo from i2c_dev_desc to decouple device enumeration from setup but did not correctly lookup the i2c_dev_desc to store the new device, instead dereferencing an uninitialized variable. Lookup the device that has already been registered by address to store the i2c client device. Fixes: 31b9887c7258 ("i3c: remove i2c board info from i2c_dev_desc") Reported-by: kernel test robot <lkp@intel.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220308134226.1042367-1-quic_jiles@quicinc.com 2022-03-08 13:42:26 +00:00




i3c: remove i2c board info from i2c_dev_desc I2C board info is only required during adapter setup so there is no requirement to keeping a pointer to it once running. To support dynamic device addition we can't rely on board info - user-space creation through sysfs won't have a boardinfo. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220117174816.1963463-2-quic_jiles@quicinc.com 2022-01-17 17:48:15 +00:00
i3c: fix uninitialized variable use in i2c setup Commit 31b9887c7258 ("i3c: remove i2c board info from i2c_dev_desc") removed the boardinfo from i2c_dev_desc to decouple device enumeration from setup but did not correctly lookup the i2c_dev_desc to store the new device, instead dereferencing an uninitialized variable. Lookup the device that has already been registered by address to store the i2c client device. Fixes: 31b9887c7258 ("i3c: remove i2c board info from i2c_dev_desc") Reported-by: kernel test robot <lkp@intel.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220308134226.1042367-1-quic_jiles@quicinc.com 2022-03-08 13:42:26 +00:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00









































i3c: master: handle IBIs in order they came IBI shall be handled in order they appear on the bus. Otherwise could hit case when order of handling them in device driver will be different. It may lead to invalid assembling fragmented packets or events order broken. Added separate workqueue with option WQ_MEM_RECLAIM for each device driver. This ensures IBI handling order and improves IBI handling performance: IBI handlers for device B are not blocked by IBI handlers for device A. Original solution (single workqueue in main driver) was able to handle also general IBI (not related to specific device) like HJ or MR. So leaving this for such purposes. Signed-off-by: Zbigniew Lukwinski <zbigniew.lukwinski@linux.intel.com> Link: https://lore.kernel.org/r/20231015222334.1652401-2-zbigniew.lukwinski@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-10-16 00:23:34 +02:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00



























































































































































































i3c: Drop support for I2C 10 bit addresing This patch drops support for I2C devices with 10 bit addressing. When I2C device with 10 bit address is defined in DT, I3C master registration fails. Address space for I2C devices has been reduced and ->i2c_funcs() hook has been removed. Because this patch series dropped support for 10 bit I2C devices, support is also dropped in Cadence I3C master driver and Synopsys DesignWare I3C master driver. Signed-off-by: Przemyslaw Gaj <pgaj@cadence.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-04-16 09:36:14 +01:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00



































i3c: fix i2c and i3c scl rate by bus mode Currently the I3C framework limits SCL frequency to FM speed when dealing with a mixed slow bus, even if all I2C devices are FM+ capable. The core was also not accounting for I3C speed limitations when operating in mixed slow mode and was erroneously using FM+ speed as the max I2C speed when operating in mixed fast mode. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <stable@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-06-19 20:36:31 +02:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00






















i3c: Allow OF-alias-based persistent bus numbering Parse the /aliases node to assign any fixed bus numbers, as is done with the i2c subsystem. Numbering for non-aliased busses will start after the highest fixed bus number. This allows an alias node such as: aliases { i3c0 = &bus_a, i3c4 = &bus_b, }; to set the numbering for a set of i3c controllers: /* fixed-numbered bus, assigned "i3c-0" / bus_a: i3c-master { }; / another fixed-numbered bus, assigned "i3c-4" / bus_b: i3c-master { }; / dynamic-numbered bus, likely assigned "i3c-5" */ bus_c: i3c-master { }; If no i3c device aliases are present, the numbering will stay as-is, starting from 0. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://lore.kernel.org/r/20230405094149.1513209-1-jk@codeconstruct.com.au Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-04-05 17:41:49 +08:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00





i3c: master: Inherit DMA masks and parameters from parent device Copy the DMA masks and parameters for an I3C master device from parent device so that the master device has them set for the DMA buffer and mapping API. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Link: https://lore.kernel.org/r/20230921055704.1087277-2-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-09-21 08:56:53 +03:00



i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00










i3c: add mixed limited bus mode The i3c bus spec defines a bus configuration where i2c devices don't have a 50ns filter but support SCL running at SDR max rate (12.5MHz). This patch introduces the limited bus mode so that users can use a higher speed in presence of i2c devices index 1. Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <linux-kernel@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-06-19 20:36:32 +02:00


i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00







i3c: fix i2c and i3c scl rate by bus mode Currently the I3C framework limits SCL frequency to FM speed when dealing with a mixed slow bus, even if all I2C devices are FM+ capable. The core was also not accounting for I3C speed limitations when operating in mixed slow mode and was erroneously using FM+ speed as the max I2C speed when operating in mixed fast mode. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <stable@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-06-19 20:36:31 +02:00


i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

i3c: fix i2c and i3c scl rate by bus mode Currently the I3C framework limits SCL frequency to FM speed when dealing with a mixed slow bus, even if all I2C devices are FM+ capable. The core was also not accounting for I3C speed limitations when operating in mixed slow mode and was erroneously using FM+ speed as the max I2C speed when operating in mixed fast mode. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <stable@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-06-19 20:36:31 +02:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00










Revert "i3c master: fix missing destroy_workqueue() on error in i3c_master_register" Adding the destroy_workqueue call in i3c_master_register introduced below kernel warning because it makes duplicate destroy_workqueue calls when i3c_master_register fails after allocating the workqueue. The workqueue will be destroyed by i3c_masterdev_release which is called by put_device at the end of the i3c_master_register function eventually in failure cases so the workqueue doesn't need to be destroyed in i3c_master_register. [ 6.972952] WARNING: CPU: 1 PID: 1 at lib/list_debug.c:48 __list_del_entry_valid+0x9c/0xf4 [ 6.982205] list_del corruption, 8fe03c08->prev is LIST_POISON2 (00000122) [ 6.989910] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 5.10.23-c12838a-dirty-31dc772 #1 [ 7.000295] Hardware name: Generic DT based system [ 7.005638] Backtrace: [ 7.008369] [<809133f0>] (dump_backtrace) from [<80913644>] (show_stack+0x20/0x24) [ 7.016819] r7:00000030 r6:60000013 r5:00000000 r4:813b5d40 [ 7.023137] [<80913624>] (show_stack) from [<8091e1a0>] (dump_stack+0x9c/0xb0) [ 7.031201] [<8091e104>] (dump_stack) from [<8011fa30>] (__warn+0xf8/0x154) [ 7.038972] r7:00000030 r6:00000009 r5:804fa1c8 r4:80b6eca4 [ 7.045289] [<8011f938>] (__warn) from [<80913d14>] (warn_slowpath_fmt+0x8c/0xc0) [ 7.053641] r7:00000030 r6:80b6eca4 r5:80b6ed74 r4:818cc000 [ 7.059960] [<80913c8c>] (warn_slowpath_fmt) from [<804fa1c8>] (__list_del_entry_valid+0x9c/0xf4) [ 7.069866] r9:96becf8c r8:818cc000 r7:8fe03c10 r6:8fe03c00 r5:8fe03ba0 r4:ff7ead4c [ 7.078513] [<804fa12c>] (__list_del_entry_valid) from [<8013f0b4>] (destroy_workqueue+0x1c4/0x23c) [ 7.088615] [<8013eef0>] (destroy_workqueue) from [<806aa124>] (i3c_masterdev_release+0x40/0xb0) [ 7.098421] r7:00000000 r6:81a43b80 r5:8fe65360 r4:8fe65048 [ 7.104740] [<806aa0e4>] (i3c_masterdev_release) from [<805f3f04>] (device_release+0x40/0xb0) [ 7.114254] r5:00000000 r4:8fe65048 [ 7.118245] [<805f3ec4>] (device_release) from [<808fe754>] (kobject_put+0xc8/0x204) [ 7.126885] r5:813978dc r4:8fe65048 [ 7.130877] [<808fe68c>] (kobject_put) from [<805f5fbc>] (put_device+0x20/0x24) [ 7.139037] r7:8fe65358 r6:8fe65368 r5:8fe65358 r4:8fe65048 [ 7.145355] [<805f5f9c>] (put_device) from [<806abac4>] (i3c_master_register+0x338/0xb00) [ 7.154487] [<806ab78c>] (i3c_master_register) from [<806ae084>] (dw_i3c_probe+0x224/0x24c) [ 7.163811] r10:00000000 r9:8fe7a100 r8:00000032 r7:819fa810 r6:819fa800 r5:8fe65040 [ 7.172547] r4:00000000 [ 7.175376] [<806ade60>] (dw_i3c_probe) from [<805fdc14>] (platform_drv_probe+0x44/0x80) [ 7.184409] r9:813a25c0 r8:00000000 r7:815ec114 r6:00000000 r5:813a25c0 r4:819fa810 [ 7.193053] [<805fdbd0>] (platform_drv_probe) from [<805fb83c>] (really_probe+0x108/0x50c) [ 7.202275] r5:815ec004 r4:819fa810 [ 7.206265] [<805fb734>] (really_probe) from [<805fc180>] (driver_probe_device+0xb4/0x190) [ 7.215492] r10:813dc000 r9:80c4385c r8:000000d9 r7:813a25c0 r6:819fa810 r5:00000000 [ 7.224228] r4:813a25c0 [ 7.227055] [<805fc0cc>] (driver_probe_device) from [<805fc5cc>] (device_driver_attach+0xb8/0xc0) [ 7.236959] r9:80c4385c r8:000000d9 r7:813a25c0 r6:819fa854 r4:819fa810 [ 7.244439] [<805fc514>] (device_driver_attach) from [<805fc65c>] (__driver_attach+0x88/0x16c) [ 7.254051] r7:00000000 r6:819fa810 r5:00000000 r4:813a25c0 [ 7.260369] [<805fc5d4>] (__driver_attach) from [<805f954c>] (bus_for_each_dev+0x88/0xc8) [ 7.269489] r7:00000000 r6:818cc000 r5:805fc5d4 r4:813a25c0 [ 7.275806] [<805f94c4>] (bus_for_each_dev) from [<805fc76c>] (driver_attach+0x2c/0x30) [ 7.284739] r7:81397c98 r6:00000000 r5:8fe7db80 r4:813a25c0 [ 7.291057] [<805fc740>] (driver_attach) from [<805f9eec>] (bus_add_driver+0x120/0x200) [ 7.299984] [<805f9dcc>] (bus_add_driver) from [<805fce44>] (driver_register+0x98/0x128) [ 7.309005] r7:80c4383c r6:00000000 r5:00000000 r4:813a25c0 [ 7.315323] [<805fcdac>] (driver_register) from [<805fedb4>] (__platform_driver_register+0x50/0x58) [ 7.325410] r5:818cc000 r4:81397c98 [ 7.329404] [<805fed64>] (__platform_driver_register) from [<80c23398>] (dw_i3c_driver_init+0x24/0x28) [ 7.339790] r5:818cc000 r4:80c23374 [ 7.343784] [<80c23374>] (dw_i3c_driver_init) from [<80c01300>] (do_one_initcall+0xac/0x1d0) [ 7.353206] [<80c01254>] (do_one_initcall) from [<80c01630>] (kernel_init_freeable+0x1a8/0x204) [ 7.362916] r8:000000d9 r7:80c4383c r6:00000007 r5:819ca2c0 r4:80c67680 [ 7.370398] [<80c01488>] (kernel_init_freeable) from [<8091eb18>] (kernel_init+0x18/0x12c) [ 7.379616] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8091eb00 [ 7.388343] r4:00000000 [ 7.391170] [<8091eb00>] (kernel_init) from [<80100148>] (ret_from_fork+0x14/0x2c) [ 7.399607] Exception stack(0x818cdfb0 to 0x818cdff8) [ 7.405243] dfa0: 00000000 00000000 00000000 00000000 [ 7.414371] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 7.423499] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 7.430879] r5:8091eb00 r4:00000000 This reverts commit 59165d16c699182b86b5c65181013f1fd88feb62. Fixes: 59165d16c699 ("i3c master: fix missing destroy_workqueue() on error in i3c_master_register") Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210408172803.24599-1-jae.hyun.yoo@linux.intel.com 2021-04-08 10:28:03 -07:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00












i3c: Add support for bus enumeration & notification This allows other drivers to be notified when new i3c busses are attached, referring to a whole i3c bus as opposed to individual devices. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> 2023-10-13 12:06:24 +08:00

i3c: master: Enable runtime PM for master controller Enable runtime PM for i3c master node during master registration time. Sometimes i3c client device driver may want to control the PM of the parent (master) to perform the transactions and save the power in an efficient way by controlling the session. Hence device can call PM APIs by passing the parent node. Here, I3C target device when calls pm_runtime_get_sync(dev->parent) couldn't invoke master drivers runtime PM callback registered by the master driver because parent's PM status was disabled in the Master node. Also call pm_runtime_no_callbacks() and pm_suspend_ignore_children() for the master node to not have any callback addition and ignore the children to have runtime PM work just locally in the driver. This should be generic and common change for all i3c devices and should not have any other impact. With these changes, I3C client device works and able to invoke master driver registered runtime PM callbacks. Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> Link: https://lore.kernel.org/r/20240228093407.4038399-1-quic_msavaliy@quicinc.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-02-28 15:04:07 +05:30



i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

i3c: Spelling s/dicovered/discovered/ Fix misspellings of "discovered". Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> 2019-10-24 17:19:01 +02:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00


























i3c: Make i3c_master_unregister() return void The function returned zero unconditionally. Switch the return type to void and simplify the callers accordingly. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20230318233311.265186-2-u.kleine-koenig@pengutronix.de Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-03-19 00:33:07 +01:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00
i3c: Add support for bus enumeration & notification This allows other drivers to be notified when new i3c busses are attached, referring to a whole i3c bus as opposed to individual devices. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> 2023-10-13 12:06:24 +08:00

i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00


i3c: master: Enable runtime PM for master controller Enable runtime PM for i3c master node during master registration time. Sometimes i3c client device driver may want to control the PM of the parent (master) to perform the transactions and save the power in an efficient way by controlling the session. Hence device can call PM APIs by passing the parent node. Here, I3C target device when calls pm_runtime_get_sync(dev->parent) couldn't invoke master drivers runtime PM callback registered by the master driver because parent's PM status was disabled in the Master node. Also call pm_runtime_no_callbacks() and pm_suspend_ignore_children() for the master node to not have any callback addition and ignore the children to have runtime PM work just locally in the driver. This should be generic and common change for all i3c devices and should not have any other impact. With these changes, I3C client device works and able to invoke master driver registered runtime PM callbacks. Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> Link: https://lore.kernel.org/r/20240228093407.4038399-1-quic_msavaliy@quicinc.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2024-02-28 15:04:07 +05:30
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00



i3c: export SETDASA method Because not all I3C drivers have the hot-join feature ready, and especially not all I3C devices support hot-join feature, exporting SETDASA method could be useful. With this function, the I3C controller could perform a DAA to I3C devices when users decide to turn these I3C devices off and on again during run-time. Tested: This change has been tested with turnning off an I3C device and turning on it again during run-time. The device driver calls SETDASA method to perform DAA to the device. And communication between I3C controller and device is set up again correctly. Signed-off-by: Jack Chen <zenghuchen@google.com> Link: https://lore.kernel.org/r/20221207205059.3848851-1-zenghuchen@google.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2022-12-07 15:50:59 -05:00


















i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00








































































i3c: master: handle IBIs in order they came IBI shall be handled in order they appear on the bus. Otherwise could hit case when order of handling them in device driver will be different. It may lead to invalid assembling fragmented packets or events order broken. Added separate workqueue with option WQ_MEM_RECLAIM for each device driver. This ensures IBI handling order and improves IBI handling performance: IBI handlers for device B are not blocked by IBI handlers for device A. Original solution (single workqueue in main driver) was able to handle also general IBI (not related to specific device) like HJ or MR. So leaving this for such purposes. Signed-off-by: Zbigniew Lukwinski <zbigniew.lukwinski@linux.intel.com> Link: https://lore.kernel.org/r/20231015222334.1652401-2-zbigniew.lukwinski@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-10-16 00:23:34 +02:00





i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00


























i3c: master: handle IBIs in order they came IBI shall be handled in order they appear on the bus. Otherwise could hit case when order of handling them in device driver will be different. It may lead to invalid assembling fragmented packets or events order broken. Added separate workqueue with option WQ_MEM_RECLAIM for each device driver. This ensures IBI handling order and improves IBI handling performance: IBI handlers for device B are not blocked by IBI handlers for device A. Original solution (single workqueue in main driver) was able to handle also general IBI (not related to specific device) like HJ or MR. So leaving this for such purposes. Signed-off-by: Zbigniew Lukwinski <zbigniew.lukwinski@linux.intel.com> Link: https://lore.kernel.org/r/20231015222334.1652401-2-zbigniew.lukwinski@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-10-16 00:23:34 +02:00





i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00





i3c: Allow OF-alias-based persistent bus numbering Parse the /aliases node to assign any fixed bus numbers, as is done with the i2c subsystem. Numbering for non-aliased busses will start after the highest fixed bus number. This allows an alias node such as: aliases { i3c0 = &bus_a, i3c4 = &bus_b, }; to set the numbering for a set of i3c controllers: /* fixed-numbered bus, assigned "i3c-0" / bus_a: i3c-master { }; / another fixed-numbered bus, assigned "i3c-4" / bus_b: i3c-master { }; / dynamic-numbered bus, likely assigned "i3c-5" */ bus_c: i3c-master { }; If no i3c device aliases are present, the numbering will stay as-is, starting from 0. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://lore.kernel.org/r/20230405094149.1513209-1-jk@codeconstruct.com.au Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-04-05 17:41:49 +08:00
i3c: support dynamically added i2c devices I2C devices can be added to the system dynamically through several sources other than static board info including device tree overlays and sysfs i2c new_device. Add an I2C bus notifier to attach the clients at runtime if they were not defined in the board info. For DT devices find the LVR in the reg property, for user-space new_device additions we synthesize a conservative setting of no spike filters and fast mode only. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220117174816.1963463-3-quic_jiles@quicinc.com 2022-01-17 17:48:16 +00:00
i3c: Allow OF-alias-based persistent bus numbering Parse the /aliases node to assign any fixed bus numbers, as is done with the i2c subsystem. Numbering for non-aliased busses will start after the highest fixed bus number. This allows an alias node such as: aliases { i3c0 = &bus_a, i3c4 = &bus_b, }; to set the numbering for a set of i3c controllers: /* fixed-numbered bus, assigned "i3c-0" / bus_a: i3c-master { }; / another fixed-numbered bus, assigned "i3c-4" / bus_b: i3c-master { }; / dynamic-numbered bus, likely assigned "i3c-5" */ bus_c: i3c-master { }; If no i3c device aliases are present, the numbering will stay as-is, starting from 0. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://lore.kernel.org/r/20230405094149.1513209-1-jk@codeconstruct.com.au Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> 2023-04-05 17:41:49 +08:00







i3c: support dynamically added i2c devices I2C devices can be added to the system dynamically through several sources other than static board info including device tree overlays and sysfs i2c new_device. Add an I2C bus notifier to attach the clients at runtime if they were not defined in the board info. For DT devices find the LVR in the reg property, for user-space new_device additions we synthesize a conservative setting of no spike filters and fast mode only. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220117174816.1963463-3-quic_jiles@quicinc.com 2022-01-17 17:48:16 +00:00












i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00




i3c: support dynamically added i2c devices I2C devices can be added to the system dynamically through several sources other than static board info including device tree overlays and sysfs i2c new_device. Add an I2C bus notifier to attach the clients at runtime if they were not defined in the board info. For DT devices find the LVR in the reg property, for user-space new_device additions we synthesize a conservative setting of no spike filters and fast mode only. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20220117174816.1963463-3-quic_jiles@quicinc.com 2022-01-17 17:48:16 +00:00
i3c: Add core I3C infrastructure Add core infrastructure to support I3C in Linux and document it. This infrastructure adds basic I3C support. Advanced features will be added afterwards. There are a few design choices that are worth mentioning because they impact the way I3C device drivers can interact with their devices: - all functions used to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is not set in stone, and if anyone needs async support, new functions can be added later on. - the bus element is a separate object, but it's tightly coupled with the master object. We thus have a 1:1 relationship between i3c_bus and i3c_master_controller objects, and if 2 master controllers are connected to the same bus and both exposed to the same Linux instance they will appear as two distinct busses, and devices on this bus will be exposed twice. - I2C backward compatibility has been designed to be transparent to I2C drivers and the I2C subsystem. The I3C master just registers an I2C adapter which creates a new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different buses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features: - I3C HDR modes are not supported - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2017-07-19 11:52:29 +02:00

3100 lines 78 KiB Raw Normal View History

3100 lines

78 KiB

Raw Normal View History