Hi, Jeremy, Apologize for the late reply. I am out of work for a long time because of my personal emergency. I am back at work now. Thank you for your interest in the development of this driver. We are working on the following items after the first submit of the patch: 1. Modify the binding file to make it focused on the device description instead of driver description. 2. Fix the codes which doesn't following the kernel development rules. 3. Re-implement the SMBus Agent function with IBI mechanism instead of polling. SMBus Agent function requires the driver to check the status register of the I3C hub. Polling the status register over I3C bus exhausts too much bus resources. I3C Hub supports reporting status changes with IBI. This shall be supported in the driver. 4. Remove the i2c slave-mqueue module. The slave-mqueue module is used to provide a user interface for SMBus Agent slave function. But it has not been included in upstream. The first two items have been finished. And we are working on the #3 and #4. I would appreciate your input on this driver. I think a review with you is very helpful. Regards, Steven -----Original Message----- From: Jeremy Kerr <jk@xxxxxxxxxxxxxxxxxxxx> Sent: Wednesday, June 19, 2024 2:56 PM To: Steven Niu <steven.niu.uj@xxxxxxxxxxx>; alexandre.belloni@xxxxxxxxxxx; linux-i3c@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; robh+dt@xxxxxxxxxx; krzysztof.kozlowski+dt@xxxxxxxxxx; conor+dt@xxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx Cc: zbigniew.lukwinski@xxxxxxxxxxxxxxx Subject: Re: [PATCH 2/2] i3c: i3c-hub: Add Renesas RG3MxxB12A1 I3C HUB driver Hi Steven, > RG3MxxB12A1 I3C HUB is smart device which provide multiple > functionality: > * Enabling voltage compatibility across I3C Controller and Target > Device. > * Enabling voltage compatibility across I3C Controller and Target > devices. > * Bus capacitance isolation. > * Address conflict isolation. > * I3C port expansion. > * Two controllers in a single I3C bus. > * I3C and SMBus device compatibility. > * GPIO expansion. Do you plan any more work on this driver? It would be great to have this included upstream, but looks like there's a fairly large amount of work required to get to that point, particularly in regards to using existing kernel infrastructure to support the device functions. Anything I can do to help there? Would a (further) review on this series be useful? Cheers, Jeremy
