Re: [PATCH 10/10] mfd: cros_ec: ec_dev-cmd_xfer() returns number of bytes received from EC

On Mon, 16 Jun 2014, Doug Anderson wrote: From: Bill Richardson wfric...@chromium.org When communicating with the EC, the cmd_xfer() function should return the number of bytes it received from the EC, or negative on error. Signed-off-by: Bill Richardson wfric...@chromium.org

Re: [PATCH 08/10] mfd: cros_ec: cleanup: Remove EC wrapper functions

diff --git a/drivers/input/keyboard/cros_ec_keyb.c b/drivers/input/keyboard/cros_ec_keyb.c index 4083796..dc37b6b 100644 --- a/drivers/input/keyboard/cros_ec_keyb.c +++ b/drivers/input/keyboard/cros_ec_keyb.c @@ -191,8 +191,18 @@ static void cros_ec_keyb_close(struct input_dev *dev)

[PATCH/RFC V7] clk: Default clock parents and rates assigned from DT

This patch adds DT binding documentation for a set of properties allowing to specify default parent clocks and clock rates in the device tree. It also adds a helper function to parse the 'assigned-clocks', 'assigned-clock-parents' and 'assigned-clock-rates' DT properties and to set the specified

[PATCH/RFC V7] clk: Support for clock parents and rates assigned from device tree

This patch adds helper functions to configure clock parents and rates as specified through 'assigned-clock-parents', 'assigned-clock-rates' DT properties for a clock provider or clock consumer device. The helpers are now being called by the bus code for the platform, I2C and SPI busses, before the

Re: [PATCH/RFC V7] clk: Support for clock parents and rates assigned from device tree

Please ignore this patch, I'll send the correct one in a while. My apologies for spamming. On 18/06/14 12:47, Sylwester Nawrocki wrote: This patch adds helper functions to configure clock parents and rates as specified through 'assigned-clock-parents', 'assigned-clock-rates' DT properties for

[PATCH/RFC V8 1/1] clk: Support for clock parents and rates assigned from device tree

This patch adds helper functions to configure clock parents and rates as specified through 'assigned-clock-parents', 'assigned-clock-rates' DT properties for a clock provider or clock consumer device. The helpers are now being called by the bus code for the platform, I2C and SPI busses, before the

[PATCH v2 07/10] mfd: cros_ec: cleanup: Remove EC wrapper functions

From: Bill Richardson wfric...@chromium.org Remove the three wrapper functions that talk to the EC without passing all the desired arguments and just use the underlying communication function that passes everything in a struct intead. This is internal code refactoring only. Nothing should

[PATCH v2 0/10] Batch of cleanup patches for cros_ec

This is a batch of cleanup patches picked from the ChromeOS 3.8 kernel tree and applied to ToT. Most of these patches were authored by Bill Richardson (CCed). Where appropriate I've squashed patches together, though I have erred on the side of keeping patches logically distinct rather than

[PATCH v2 09/10] mfd: cros_ec: ec_dev-cmd_xfer() returns number of bytes received from EC

From: Bill Richardson wfric...@chromium.org When communicating with the EC, the cmd_xfer() function should return the number of bytes it received from the EC, or negative on error. Signed-off-by: Bill Richardson wfric...@chromium.org Signed-off-by: Doug Anderson diand...@chromium.org Acked-by:

[PATCH] i2c: s3c2410: resume the I2C controller earlier

From: Vincent Palatin vpala...@chromium.org When the wake-up is triggered by the PMIC RTC, the RTC driver is trying to read the PMIC interrupt status over I2C and fails because the I2C controller is not resumed yet. Let's resume the I2C controller earlier in the _noirq phase (as other hardwares

[PATCH] i2c: exynos5: Properly use the noirq variants of suspend/resume

The original code for the exynos i2c controller registered for the noirq variants. However during review feedback it was moved to SIMPLE_DEV_PM_OPS without anyone noticing that it meant we were no longer actually noirq (despite functions named exynos5_i2c_suspend_noirq and

Re: [PATCH] i2c: s3c2410: resume the I2C controller earlier

Hi, On Wed, Jun 18, 2014 at 9:54 PM, Doug Anderson diand...@chromium.org wrote: From: Vincent Palatin vpala...@chromium.org When the wake-up is triggered by the PMIC RTC, the RTC driver is trying to read the PMIC interrupt status over I2C and fails because the I2C controller is not resumed