In general, it's considered bad form to do this:

1. Have a device "Master" that is i2c master
2. Have it connected via i2c to another device "Slave"
3. Reset "Master" without resetting "Slave".

---

Why is this bad?  If we don't do this then we need to add "unwedge" code to the kernel somewhere.  That's possible, but slightly less than ideal.

For some history about wedged i2c busses, you can see:

  https://chromium-review.googlesource.com/c/32168/

...but in general the i2c bus is stateful.  If the master gets reset but the slave doesn't then we need to do something to get them back in sync.  In the worst case we'll reset the master right as the slave was driving the lines in which case the bus will be fully wedged until we unwedge things.

---

So why talk about i2c and wedging here?  The rt5514 codec is connected to the rk3399 AP.  ...but it's powered by a rail (pp1800_lid) that is turned on any time we're not in S5.  That means we can potentially get wedged.

The easiest fix for this is to just power cycle this rail when the EC sees that the AP wants a warm reset.  This seems like a totally sane thing to do anyway.


NOTE: on some gru children (like Bob) things are even worse because of the way that PP1800_AUDIO powers up.  On these boards a reboot can cause a phantom glitch on the rt5514 and wedge things up even more often.  See b/36666089