> This could indeed be moved into the reset driver. However, that
> means the reset driver needs to become aware of the peculiarities
> of the various target devices on the various SoCs.  We already have
> something similar for module stop delays on RZ/V2H, though.
> And it means more dependencies to track when adding driver support.
> 
> Then there's still the user in the PCIe driver[2], which can't be
> handled like that.

I can see the argument that the extra code could live in the reset
handler. But given the harder dependency tracking plus the inability to
handle all corner cases in the reset driver anyhow, I tend to update the
handling in this I2C driver.