linux/drivers/i3c, branch v6.3

Merge tag 'i3c/for-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux

2023-03-01T00:05:01Z

Pull i3c updates from Alexandre Belloni: "Subsystem: - transfer pid from boardinfo to device info Drivers: - dw-i3c-master: stop hardcoding initial speed" * tag 'i3c/for-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux: i3c: master: dw: stop hardcoding initial speed i3c: transfer pid from boardinfo to device info

i3c: master: dw: stop hardcoding initial speed

2023-02-28T22:54:49Z

Bus-speed could be default(12.5MHz) or defined by users in dts. Dw-i3c-master should not hard-code the initial speed to be I3C_BUS_TYP_I3C_SCL_RATE (12.5MHz) And because of Synopsys's I3C controller limit (hcnt/lcnt register length) and core-clk provided, there is a limit to bus speed, too. For example, when core-clk is 250 MHz, the bus speed cannot be lowered below 1MHz. Tested: tested with an i3c sensor and captured with a logic analyzer. Signed-off-by: Jack Chen Link: https://lore.kernel.org/r/20230216151057.293764-1-zenghuchen@google.com Signed-off-by: Alexandre Belloni

i3c: transfer pid from boardinfo to device info

2023-02-25T22:03:51Z

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 Link: https://lore.kernel.org/r/20230105212952.56321-1-zenghuchen@google.com Signed-off-by: Alexandre Belloni

driver core: make struct device_type.uevent() take a const *

2023-01-27T12:45:36Z

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 Cc: Andreas Noever Cc: Andy Shevchenko Cc: Bard Liao Cc: Chaitanya Kulkarni Cc: Dan Williams Cc: Dmitry Torokhov Cc: Frank Rowand Cc: Ira Weiny Cc: Jason Gunthorpe Cc: Jens Axboe Cc: Jilin Yuan Cc: Jiri Slaby Cc: Len Brown Cc: Mark Gross Cc: "Martin K. Petersen" Cc: "Matthew Wilcox (Oracle)" Cc: Maximilian Luz Cc: Michael Jamet Cc: Ming Lei Cc: Pierre-Louis Bossart Cc: Rob Herring Cc: Sakari Ailus Cc: Sanyog Kale Cc: Sean Young Cc: Stefan Richter Cc: Thomas Gleixner Cc: Won Chung Cc: Yehezkel Bernat Acked-by: Rafael J. Wysocki Acked-by: Mika Westerberg # for Thunderbolt Acked-by: Mauro Carvalho Chehab Acked-by: Alexandre Belloni Acked-by: Heikki Krogerus Acked-by: Wolfram Sang Acked-by: Vinod Koul Acked-by: Hans de Goede Link: https://lore.kernel.org/r/20230111113018.459199-6-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

i3c: move dev_to_i3cdev() to use container_of_const()

2023-01-27T12:45:32Z

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 Acked-by: Hans de Goede Link: https://lore.kernel.org/r/20230111113018.459199-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

i3c: export SETDASA method

2022-12-11T20:25:58Z

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 Link: https://lore.kernel.org/r/20221207205059.3848851-1-zenghuchen@google.com Signed-off-by: Alexandre Belloni

i3c: master: Remove the wrong place of reattach.

2022-10-12T21:45:29Z

The reattach should be used when an I3C device has its address changed. But the modified place in this patch doesn't have the address changed of the newdev. This wrong reattach will reserve the same address slot twice and return unexpected -EBUSY when the bus find the duplicate device with diffent dynamic address. Signed-off-by: Billy Tsai Link: https://lore.kernel.org/r/20220926105145.8145-2-billy_tsai@aspeedtech.com Signed-off-by: Alexandre Belloni

i3c: master: Free the old_dyn_addr when reattach.

2022-10-12T21:45:29Z

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 Link: https://lore.kernel.org/r/20220926105145.8145-1-billy_tsai@aspeedtech.com Signed-off-by: Alexandre Belloni

i3c: master: svc: fix returnvar.cocci warning

2022-05-17T20:34:42Z

Fix the following coccicheck warning: drivers/i3c/master/svc-i3c-master.c:1600:5-8: Unneeded variable: "ret". Return "0" on line 1605. Signed-off-by: Guo Zhengkui Reviewed-by: Miquel Raynal Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220504164901.9622-1-guozhengkui@vivo.com

i3c/master: simplify the return expression of i3c_hci_remove()

2022-05-17T20:33:43Z

Simplify the return expression. Reported-by: Zeal Robot Signed-off-by: Minghao Chi Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220505021954.54524-1-chi.minghao@zte.com.cn