Hi Greg,

On Sun, 11 Nov 2018 09:39:32 -0800
Greg Kroah-Hartman [off-list ref] wrote:

On Fri, Oct 26, 2018 at 04:43:24PM +0200, Boris Brezillon wrote:

quoted

Hi Greg,

I think we've reached a point where we can eventually consider the I3C
framework for inclusion in 4.20 (5.0?). A few more issues were reported
on v9 and fixed in v10. I can't guarantee that the implementation is
free of bugs but I still think it's worth merging it in v4.20: it's a
new subsystem, so we don't risk regressions, and the only way we can
detect other issues is by having other people experiment with this
implementation.

The only remaining concern raised by Arnd is the fact that both hosts
and slaves share the same bus type and are differentiated thanks to
their device_type, which IMHO is fine since this is what other
subsystems do (plus I don't see other solutions to have both I3C
devices and I3C buses represented under /sys/bus/i3c/).  

Yeah, it's not the nicest, but it will work, we did it also for USB and
greybus and it solves the issue.

This all looks good to me, so I've queued it up.  Let's see if
linux-next has any problems with it.

I recently asked Stephen to add the linux-i3c tree to linux-next, so
I'm expecting conflicts :-/. Sorry, I didn't know you were planning to
take these patches through your tree.

BTW, I also fixed a couple of things when rebasing on top of 4.20-rc1:

- KernelVersion in the sysfs ABI doc has been updated to 5.0
- Fixed i3c_master_getmxds_locked() (bug reported/fixed by Colin here
  https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1799850.html)
- Removed a blank line at the end of master-driver-api.rst

For the record, the i3c/next branch pulled by Stephen is available here
[1].

Thanks for sticking with it, nice work!

Thanks for reviewing it! Greg, Stephen, let me know if you want me to
reset i3c/next to v4.20-rc1 to avoid conflicts in linux-next.

Regards,

Boris

[1]https://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git/log/?h=i3c/next