The haphazard caching idiom in "inv_mpu.c", via "struct chip_cfg_s" is broken.
One can see (that you would hope any dev would do before releasing) by simply stepping though mpu_init() in a debugger that default values set as 0xFF (or -1) are being read as valid flag or values and not universally as the "uncached value flag" that was probably intended.
To do this right, and to be bug free, since there is no out of range unique value et al, each value needs a separate flag/value to truly track if a value is a valid cached or not. Could be done using C macros; the downside is that each value would probably need extra byte (perhaps minimal and more complex a single bit flag) for when RAM is often a precious commodity for embedded systems.
Checks could be compile switched in for debug builds.
For that matter since we are probably talking mostly initialization code, the value of caching a lot of things is arguable; especially when there is so much redundancy in mpu_init(). Meaning all the defaults being set like "mpu_set_gyro_fsr(2000)" in there where if I want something different I have to redundantly call "mpu_set_gyro_fsr()" anyhow after. And a lot of wacky turning things on and off in there when they are already off anyhow after the device is reset with PWR_MGMT_1->BIT_RESET at the beginning.
So the I2C performance gain (what I assume the design consideration was) is probably lost in all that anyhow.
Incidentally, by simply adding as a big argument list to mpu_init() with things like FSR, etc., there would be no need for calling the "setters" more than once.