| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 <[email protected]>
Reviewed-by: Alex Elder <[email protected]>
Acked-by: Sumit Garg <[email protected]>
Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
In MIPI I3C Specification:
"Ninth Bit of SDR Target Returned (Read) Data as End-of-Data: In I2C, the
ninth Data bit from Target to Controller is an ACK by the Controller. By
contrast, in I3C this bit allows the Target to end a Read, and allows the
Controller to Abort a Read. In SDR terms, the ninth bit of Read data is
referred to as the T-Bit (for ‘Transition’)"
I3C allow devices early terminate data transfer. So need "actual_len" field
to indicate how much get by i3c_priv_xfer.
Reviewed-by: Miquel Raynal <[email protected]>
Signed-off-by: Frank Li <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>
|
|
The MIPI I3C spec refers to a Provisioned ID, since it is (sometimes)
provisioned at device manufacturing.
Signed-off-by: Matt Johnston <[email protected]>
Acked-by: Rob Herring <[email protected]>
Reviewed-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>
|
|
Fix all kernel-doc warnings in <linux/i3c/device.h>:
include/linux/i3c/device.h:27: warning: contents before sections
include/linux/i3c/device.h:196: warning: Excess function parameter 'dev' description in 'dev_to_i3cdev'
Fixes: fa838c8ce537 ("i3c: move dev_to_i3cdev() to use container_of_const()")
Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure")
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Boris Brezillon <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Alexandre Belloni <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
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 <[email protected]>
Cc: Andreas Noever <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Bard Liao <[email protected]>
Cc: Chaitanya Kulkarni <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Dmitry Torokhov <[email protected]>
Cc: Frank Rowand <[email protected]>
Cc: Ira Weiny <[email protected]>
Cc: Jason Gunthorpe <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: Jilin Yuan <[email protected]>
Cc: Jiri Slaby <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Mark Gross <[email protected]>
Cc: "Martin K. Petersen" <[email protected]>
Cc: "Matthew Wilcox (Oracle)" <[email protected]>
Cc: Maximilian Luz <[email protected]>
Cc: Michael Jamet <[email protected]>
Cc: Ming Lei <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Sakari Ailus <[email protected]>
Cc: Sanyog Kale <[email protected]>
Cc: Sean Young <[email protected]>
Cc: Stefan Richter <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Won Chung <[email protected]>
Cc: Yehezkel Bernat <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Acked-by: Mika Westerberg <[email protected]> # for Thunderbolt
Acked-by: Mauro Carvalho Chehab <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Acked-by: Heikki Krogerus <[email protected]>
Acked-by: Wolfram Sang <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
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 <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>
|
|
Present definition for module_i3c_i2c_driver uses only the
1st argument i.e., struct i3c_driver.
Irrespective of CONFIG_I3C being enabled/disabled,
struct i2c_driver is never passed to module_driver()
Passing struct i2c_driver as the 4th argument works.
Signed-off-by: Akshay Gupta <[email protected]>
Signed-off-by: Naveen Krishna Chatradhi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexandre Belloni <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
|