summaryrefslogtreecommitdiff
path: root/drivers/i3c/device.c
AgeCommit message (Collapse)AuthorFilesLines
2024-05-23i3c: Add comment for -EAGAIN in i3c_device_do_priv_xfers()Frank Li1-0/+4
In accordance with I3C spec ver 1.1.1 09-Jun-2021, section: 5.1.2.2.3, if a target requests hot join (HJ), In-Band Interrupt (IBI), or controller role request (CRR) during the emission of an I3C address in i3c_device_do_priv_xfers(), the target may win bus arbitration. In such cases, it is imperative to notify the I3C client driver and retry i3c_device_do_priv_xfers() after some delay. Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20240506164009.21375-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2023-01-27driver core: make struct device_type.uevent() take a const *Greg Kroah-Hartman1-1/+1
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-27i3c: move dev_to_i3cdev() to use container_of_const()Greg Kroah-Hartman1-12/+0
The driver core is changing to pass some pointers as const, so move dev_to_i3cdev() to use container_of_const() to handle this change. dev_to_i3cdev() now properly keeps the const-ness of the pointer passed into it, while as before it could be lost. Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230111113018.459199-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-11i3c: export SETDASA methodJack Chen1-0/+20
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>
2021-02-02i3c: Handle drivers without probe or remove callbackUwe Kleine-König1-0/+5
A registered driver without a probe callback doesn't make sense, so refuse to register such a driver. (Otherwise i3c_device_probe() yields a NULL pointer exception.) A driver without remove is possible, e.g. when all resources are freed using devm callbacks. So guard the call to driver->remove by a check for being non-NULL. Note that the only in-tree i3c driver (drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i3c.c) doesn't have a remove callback. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210128091048.17006-1-u.kleine-koenig@pengutronix.de
2020-02-28i3c: Simplify i3c_device_match_id()Boris Brezillon1-28/+22
Simply match against ->match_flags instead of trying to be smart and fix drivers inconsistent ID tables. 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/8c5d6523e1c161783db834a3447954f7fd6267e6.1582796652.git.vitor.soares@synopsys.com
2019-07-27i3c: move i3c_device_match_id to device.c and export itVitor Soares1-0/+53
Some I3C device drivers need to know which entry matches the i3c_device object passed to the probe function Let's move i3c_device_match_id() to device.c and export it so it can be used by drivers. Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2018-11-12i3c: Add core I3C infrastructureBoris Brezillon1-0/+233
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>