I have not read much of the I3C spec. I'm just coming from the
current situation with I2C and the i2c-demux-pinctrl driver which
tries to retrofit this into the I2C world and is not doing a grand
job. And how could it?

If you can acknowledge that i2c-demux-pinctrl is needed for I2C
but for some reason is not needed for I3C because of something
that differs between I2C and I3C, then fine, by all means ditch
the explicit bus object.

But in my mind splitting up the devices on the same bus between
several of our own masters and then not have a single object for
the bus is going to cause headaches down the line. Be it address
clashes or trouble with master ping-pong or whatever.

I think the reason for i2c-demux-pinctrl is that some (most?) I2C
hardware suffers from quirks and one way to work around it is to
make selected accesses from a different master. I expect I3C HW
to also suffer from quirks...

Maybe a bit-bang I3C master isn't feasible for some fundamental
reason? But if it is, then I'd say that it's just a matter of time
until someone finds a situation where such a thing could be used to
work around some I3C quirk. And then it might be too expensive to
always use the bit-bang master for the affected device.

But what do I know? Don't let me hold this series back...

Thanks, Peter. You nailed it, the I2C use case (and its limits). From
what I know about I3C, bit-banging doesn't sound very feasible to me, so
the situation might be a bit different. Still, no one knows about future
I3C use cases and HW quirks. This is why I encouraged the seperate bus
object because back then it was said it was easy to do and implement. If
this now becomes a show-stopper, we can surely re-decide. I am not
strong on this point, it was just something which would have helped I2C.
(And for that matter, we (= the Renesas Upstream Kernel Team) was
discussing something similar to the i2c demuxer for SPI, too. We have
multiple IP cores which can do SPI on R-Car, all with their pros and
cons)