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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140519105055.GA2612@katana>
Date:	Mon, 19 May 2014 12:50:56 +0200
From:	Wolfram Sang <wsa@...-dreams.de>
To:	Doug Anderson <dianders@...omium.org>
Cc:	lee.jones@...aro.org, swarren@...dia.com, abrestic@...omium.org,
	dgreid@...omium.org, olof@...om.net, sjg@...omium.org,
	linux-samsung-soc@...r.kernel.org, linux-tegra@...r.kernel.org,
	Vincent Palatin <vpalatin@...omium.org>, robh+dt@...nel.org,
	pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	rdunlap@...radead.org, sameo@...ux.intel.com, jdelvare@...e.de,
	shane.huang@....com, maxime.ripard@...e-electrons.com,
	laurent.pinchart+renesas@...asonboard.com,
	u.kleine-koenig@...gutronix.de, bjorn.andersson@...ymobile.com,
	kevin.strasser@...ux.intel.com, linux@...sktech.co.nz,
	andrew@...n.ch, andriy.shevchenko@...ux.intel.com,
	schwidefsky@...ibm.com, matt.porter@...aro.org,
	ch.naveen@...sung.com, devicetree@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-i2c@...r.kernel.org
Subject: Re: [PATCH v3 6/7] i2c: ChromeOS EC tunnel driver


> +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@...-dreams.de>

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


Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)