Re: [PATCH v3 6/7] i2c: ChromeOS EC tunnel driver

[Wolfram Sang <wsa@the-dreams.de>]

[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]


> +I2C bus that tunnels through the ChromeOS EC (cros-ec)
> +======================================================
> +On some ChromeOS board designs we've got a connection to the EC (embedded
> +controller) but no direct connection to some devices on the other side of
> +the EC (like a battery and PMIC).  To get access to those devices we need
> +to tunnel our i2c commands through the EC.
> +
> +The node for this device should be under a cros-ec node like google,cros-ec-spi
> +or google,cros-ec-i2c.
> +
> +
> +Required properties:
> +- compatible: google,cros-ec-i2c-tunnel
> +- google,remote-bus: The EC bus we'd like to talk to.
> +
> +Optional child nodes:
> +- One node per I2C device connected to the tunnelled I2C bus.
> +
> +
> +Example:
> +	cros-ec@0 {
> +		compatible = "google,cros-ec-spi";

Ooookay, now I get it. From the compatible name of this snipplet, I
assumed this node describes only an SPI IP core inside the EC. This is
why I complained about the location of the I2C busses, since placing it
as subnodes of the EC based SPI didn't make sense to me, even though the
connection of the tunnel was SPI. Now I understand that this is the core
driver for the EC, talking to it via SPI. Since this driver is an SPI
child node I would not have expected the "-spi" suffix. Sorry, for this
confusion :/ Now, the bindings make much more sense to me.

> +			google,remote-bus = <0>;

I am still not too happy about this one, but it is good enough for now,
I suppose.

Code looks good, so

Reviewed-by: Wolfram Sang <wsa@the-dreams.de>

I don't mind how it gets upstream. I can take it, but you can also keep
it in this series.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]