- 15 6月, 2015 3 次提交
-
-
由 Stephen Barber 提交于
Add support in cros_ec.c to handle EC host command protocol v3. For v3+, probe for maximum shared protocol version and max request, response, and passthrough sizes. For now, this will always fall back to v2, since there is no bus-specific code for handling proto v3 packets. Signed-off-by: NStephen Barber <smbarber@chromium.org> Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk> Reviewed-by: NGwendal Grignou <gwendal@chromium.org> Tested-by: NGwendal Grignou <gwendal@chromium.org> Tested-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NLee Jones <lee.jones@linaro.org> Acked-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
由 Javier Martinez Canillas 提交于
Commit 1b84f2a4 ("mfd: cros_ec: Use fixed size arrays to transfer data with the EC") modified the struct cros_ec_command fields to not use pointers for the input and output buffers and use fixed length arrays instead. This change was made because the cros_ec ioctl API uses that struct cros_ec_command to allow user-space to send commands to the EC and to get data from the EC. So using pointers made the API not 64-bit safe. Unfortunately this approach was not flexible enough for all the use-cases since there may be a need to send larger commands on newer versions of the EC command protocol. So to avoid to choose a constant length that it may be too big for most commands and thus wasting memory and CPU cycles on copy from and to user-space or having a size that is too small for some big commands, use a zero-length array that is both 64-bit safe and flexible. The same buffer is used for both output and input data so the maximum of these values should be used to allocate it. Suggested-by: NGwendal Grignou <gwendal@chromium.org> Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NLee Jones <lee.jones@linaro.org> Acked-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
由 Gwendal Grignou 提交于
Parent and device were pointing to the same device structure. Parent is unused, removed. Signed-off-by: NGwendal Grignou <gwendal@chromium.org> Tested-by: NStephen Barber <smbarber@chromium.org> Tested-by: NHeiko Stuebner <heiko@sntech.de> Tested-by: NGwendal Grignou <gwendal@chromium.org> Reviewed-by: NPuthikorn Voravootivat <puthik@chromium.org> Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
- 05 3月, 2015 2 次提交
-
-
由 Javier Martinez Canillas 提交于
The driver uses the inb() and outb() I/O functions so should include the header file that has these functions definitions. This patch fixes the following error when the header is not explicitly included: drivers/platform/chrome//cros_ec_lpc.c: In function ‘ec_response_timed_out’: drivers/platform/chrome//cros_ec_lpc.c:40:3: error: implicit declaration of function ‘inb’ [-Werror=implicit-function-declaration] drivers/platform/chrome//cros_ec_lpc.c: In function ‘cros_ec_cmd_xfer_lpc’: drivers/platform/chrome//cros_ec_lpc.c:75:3: error: implicit declaration of function ‘outb’ [-Werror=implicit-function-declaration] Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 kbuild test robot 提交于
drivers/platform/chrome/cros_ec_lpc.c:272:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci CC: Bill Richardson <wfrichar@chromium.org> Signed-off-by: NFengguang Wu <fengguang.wu@intel.com> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
- 27 2月, 2015 1 次提交
-
-
由 Bill Richardson 提交于
Chromebooks have an Embedded Controller (EC) that is used to implement various functions such as keyboard, power and battery. The AP can communicate with the EC through different bus types such as I2C, SPI or LPC. The cros_ec mfd driver is then composed of a core driver that register the sub-devices as mfd cells and provide a high level communication interface that is used by the rest of the kernel and bus specific interfaces modules. Each connection method then has its own driver, which register with the EC driver interface-agnostic interface. Currently, there are drivers to communicate with the EC over I2C and SPI and this driver adds support for LPC. Signed-off-by: NBill Richardson <wfrichar@chromium.org> Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by: NGwendal Grignou <gwendal@chromium.org> Reviewed-by: NGwendal Grignou <gwendal@chromium.org> Signed-off-by: NOlof Johansson <olof@lixom.net>
-