Unlike I²C, there is no natural way to hang the I3C Bus. In I²C, clock stretching (where the Target holds the clock low, stopping it from operating) often causes serious problems with no fix: there’s simply no way to get the Target’s attention if it has hung the Bus. By contrast, in I3C only the Controller drives the clock, and so the Target performs all actions on SDA relative to that clock, thereby eliminating the normal causes of such hangs.
Further, since I3C is designed to ensure that I3C Targets can operate their back-end I3C peripheral off the SCL clock (vs. oversampling), any problems elsewhere in the Target won’t translate into Bus hangs.
If a system implementer is highly concerned about a Target accidently locking itself, then a separate
hard-reset line could be used. Alternatively, the I3C v1.1.1 and I3C Basic v1.1.1 specifications add a new feature called Target Reset for resetting non-responsive I3C Targets: if an I3C Controller emits the Target Reset Pattern (a defined unique Bus pattern that does not otherwise occur during regular communication), then the Devices on the Bus will treat it just like a hardwired reset line.
This question has been updated for I3C v1.1.1 and I3C Basic v1.1.1.