The r8a7790/lager and r8a7791/koelsch development boards have da9063 and
da9210 regulators. Both regulators have their interrupt request lines
tied to the same interrupt pin (IRQ2) on the SoC.

After cold boot or da9063-induced restart, both the da9063 and da9210
seem to assert their interrupt request lines. Hence as soon as one
driver requests this irq, it gets stuck in an interrupt storm, as it
only manages to deassert its own interrupt request line, and the other
driver hasn't installed an interrupt handler yet.

To handle this, install a quirk that masks the interrupts in both the
da9063 and da9210. This quirk has to run after the i2c master driver
has been initialized, but before the i2c slave drivers are initialized.
As it depends on i2c, select I2C if one of the affected platforms is
enabled in the kernel config.

Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
Tested-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx>
Reviewed-by: Mark Brown <broonie@xxxxxxxxxx>
---
v2:
- Add Tested-by, Reviewed-by,
- Add check for "renesas,lager", which is known to be affected (thanks
Wolfram),
- Make ARCH_R8A7790 and ARCH_R8A7791 select I2C, as the quirk needs
i2c to be builtin, and drop the #ifdef on CONFIG_I2C,
- Use the passed notifier_block to unregister the notifier, so we can
get rid of the forward declaration,
- Move the quirk code to a separate file for easier maintenance,
- Postpone iounmap() until after bus_unregister_notifier(),
- Remove error checking for bus_{,un}register_notifier(); these
currently cannot fail, and if they ever do, there's nothing we can
do about it,
- Comment rewording and restructuring,
- Drop RFC state.

I do not have schematics for r8a7793/gose, but according to the BSP, it
has both da9210 and da9063, so most probably it's also affected.