On eve:

[    3.379910] tpm tpm0: tpm_transmit: tpm_send: error -5
[    3.380450] tpm_tis: probe of tpm_tis failed with error -5
...
[    4.068529] tpm tpm0: A TPM error (1407) occurred disabling deep-sleep

Eve is fine. The first two lines from comment #1 are for the other, default tpm drivers, which fails to find a chip.
The third line actually indicates that tpm0 device was successfully created and is in use. The error itself for that command is expected. Searching for cr50_i2c in the log should show a successful probe by that driver.

#2: Confirmed.

[    4.032680] cr50_i2c i2c-GOOG0005:00: cr50 TPM 2.0 (i2c 0x50 irq 24 id 0x28)

For caroline, are those the only tpm-related lines in the log?
Anything from tpm_tis_spi? Do we have TCG_TIS_SPI set for caroline? not sure what's used in 3.18 for caroline, but this is the driver that has .compatible = "infineon,slb9670" in OF table.

CONFIG_TCG_TIS_SPI is not enabled, but it is not enabled in chromeos-3.18 either (unless I am somehow missing it).

Those are the only tpm messages in the log.

I think the issue is that the device tries to instantiate (so the driver is there), but the memory range is not available. /proc/iomem shows:
  fed40000-fed44fff : tpm_tis
    fed40000-fed44fff : PCI Bus 0000:00
      fed40000-fed44fff : tpm_tis

/sys/devices/platform/tpm_tis/tpm/tpm0 exists and reports data.

active:1
caps:Manufacturer: 0x49465800
caps:TCG version: 1.2
caps:Firmware version: 6.40
dev:10:224
durations:1000000 1500000 150000000 [original]
enabled:1
owned:0

and so on.

Is the device somehow instantiated twice ? Almost looks like it.

Looks like it is attempting to talk to 9670 through memory-mapped registers as opposed to SPI. 
What tpm_tis initialization does is it first tries the fixed address range starting with 0xFED40000. Could have succeeded at this point. Then it proceeds with handling tpm_tis platform device and ACPI info (#ifdef CONFIG_ACPI). If it is present again there, it may fail to map over the same range? In 3.18 we didn't have this sequence but had either "tpm_tis" platform or pnp_driver_register based on the force flag.

Looks like in init_tis we need to distinguish between tpm_tis_force_device() returning 0 because it registered the device and returning 0 because force flag was not set.
And I believe force is set in the kernel command line (what does the log say?).

Well, there's no acpi_bus_register_driver in init_tis in 4.14 (I was looking at 4.4). Still, it does:
1) tpm_tis_force_device - which may succeed
2) platform_driver_register("tpm_tis") based on OF / ACPI
3) pnp_register_driver (if CONFIG_PNP)

So, 2 or 3 could attempt to repeat what was already done by 1. (Or 3 repeat what was done by 2). The init doesn't stop after one succeeds, it just keep going.

BTW, any chance /dev/tpm0 is there and working after all this? Maybe it's all WAI: the 2nd probe failed, but the device was created after the first attempt and works fine?

Command line has "tpm_tis.force=1 tpm_tis.interrupts=0". 

Yes, /dev/tpm0 is there, and it looks like it is working.
The code is still broken, though, since the init call returns an error when it should not.