Re: [PATCH v2 0/7] Second batch of cleanups for cros_ec
Hello Dmitry, On 08/25/2014 08:01 PM, Dmitry Torokhov wrote: On Mon, Aug 25, 2014 at 07:28:01PM +0200, Javier Martinez Canillas wrote: #7 does not apply to my tree (I guess it depends on the 1st batch which I expect will go through MFD tree?). Maybe you could rebase it on top of my next so it can be applied sooner? Or it really needs parts of patchset #1? The first batch sent by Doug did indeed touch this driver and the patches were merged through the MFD tree for 3.17 as you said. I see that your next branch is based on 3.16-rc6 and that is why it does not apply cleanly. I guess you will rebase your next branch for 3.18 on top of 3.17-rc1 anyways which will fix this issue? If not please let me know and I can of course re-spin the patch so it applies cleanly on top of 3.16-rc6. I normally merge with mainline around -rc3 so please ping me around that time if you do not see the patch in my tree. Will do, thanks a lot for your help! Thanks. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] Second batch of cleanups for cros_ec
This is a second batch of cleanups patches for the mfd cros_ec driver and its subdevices drivers. The first batch of cleanups was posted by Doug Anderson [0] and have already been merged. The patches were picked from the ChromeOS 3.8 kernel and after these no cleanups patches for cros_ec are left, only commits that add cros ec support not yet available in mainline. This is a second version of the patch series that addresses issues pointed out by Doug Anderson and Lee Jones on v1 [1]. There is almost no functionality added on this series but the idea is to reduce the delta between the mainline drivers and the ones in the downstream Chrome OS 3.8 kernel so the missing functionality can be added on top once these cleanups patches are merged. The missing functionlity currently in mainline is: - Chrome OS Embedded Controller userspace device interface - Chrome OS Embedded Controller Low Pin Count (LPC) inteface - Access to vboot context stored on a block device - Access to vboot context stored on EC's nvram The patches in this series are authored by different people (all on cc) and consist of the following: Andrew Bresticker (3): mfd: cros_ec: stop calling -cmd_xfer() directly mfd: cros_ec: move locking into cros_ec_cmd_xfer mfd: cros_ec: wait for completion of commands that return IN_PROGRESS Derek Basehore (1): i2c: i2c-cros-ec-tunnel: Set retries to 3 Doug Anderson (1): mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC Todd Broch (2): mfd: cros_ec: Instantiate sub-devices from device tree Input: cros_ec_keyb: Optimize ghosting algorithm. drivers/i2c/busses/i2c-cros-ec-tunnel.c | 5 +- drivers/input/keyboard/cros_ec_keyb.c | 94 ++--- drivers/mfd/cros_ec.c | 78 --- drivers/mfd/cros_ec_spi.c | 20 --- include/linux/mfd/cros_ec.h | 24 ++--- 5 files changed, 141 insertions(+), 80 deletions(-) Patches #1, #2, #6 and #7 do not depend of others so they can be merged independently but patches #3, #4 and #5 have to be merged in that specific order since they depend on the previous one. Best regards, Javier [0]: https://lkml.org/lkml/2014/6/16/681 [1]: http://comments.gmane.org/gmane.linux.drivers.i2c/19256 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] Second batch of cleanups for cros_ec
On Mon, Aug 25, 2014 at 03:40:01PM +0200, Javier Martinez Canillas wrote: This is a second batch of cleanups patches for the mfd cros_ec driver and its subdevices drivers. The first batch of cleanups was posted by Doug Anderson [0] and have already been merged. The patches were picked from the ChromeOS 3.8 kernel and after these no cleanups patches for cros_ec are left, only commits that add cros ec support not yet available in mainline. This is a second version of the patch series that addresses issues pointed out by Doug Anderson and Lee Jones on v1 [1]. There is almost no functionality added on this series but the idea is to reduce the delta between the mainline drivers and the ones in the downstream Chrome OS 3.8 kernel so the missing functionality can be added on top once these cleanups patches are merged. The missing functionlity currently in mainline is: - Chrome OS Embedded Controller userspace device interface - Chrome OS Embedded Controller Low Pin Count (LPC) inteface - Access to vboot context stored on a block device - Access to vboot context stored on EC's nvram The patches in this series are authored by different people (all on cc) and consist of the following: Andrew Bresticker (3): mfd: cros_ec: stop calling -cmd_xfer() directly mfd: cros_ec: move locking into cros_ec_cmd_xfer mfd: cros_ec: wait for completion of commands that return IN_PROGRESS Derek Basehore (1): i2c: i2c-cros-ec-tunnel: Set retries to 3 Doug Anderson (1): mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC Todd Broch (2): mfd: cros_ec: Instantiate sub-devices from device tree Input: cros_ec_keyb: Optimize ghosting algorithm. drivers/i2c/busses/i2c-cros-ec-tunnel.c | 5 +- drivers/input/keyboard/cros_ec_keyb.c | 94 ++--- drivers/mfd/cros_ec.c | 78 --- drivers/mfd/cros_ec_spi.c | 20 --- include/linux/mfd/cros_ec.h | 24 ++--- 5 files changed, 141 insertions(+), 80 deletions(-) Patches #1, #2, #6 and #7 do not depend of others so they can be merged independently but patches #3, #4 and #5 have to be merged in that specific order since they depend on the previous one. #7 does not apply to my tree (I guess it depends on the 1st batch which I expect will go through MFD tree?). Maybe you could rebase it on top of my next so it can be applied sooner? Or it really needs parts of patchset #1? Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] Second batch of cleanups for cros_ec
Hello Dmitry, On 08/25/2014 07:05 PM, Dmitry Torokhov wrote: Patches #1, #2, #6 and #7 do not depend of others so they can be merged independently but patches #3, #4 and #5 have to be merged in that specific order since they depend on the previous one. #7 does not apply to my tree (I guess it depends on the 1st batch which I expect will go through MFD tree?). Maybe you could rebase it on top of my next so it can be applied sooner? Or it really needs parts of patchset #1? The first batch sent by Doug did indeed touch this driver and the patches were merged through the MFD tree for 3.17 as you said. I see that your next branch is based on 3.16-rc6 and that is why it does not apply cleanly. I guess you will rebase your next branch for 3.18 on top of 3.17-rc1 anyways which will fix this issue? If not please let me know and I can of course re-spin the patch so it applies cleanly on top of 3.16-rc6. Thanks. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] Second batch of cleanups for cros_ec
On Mon, Aug 25, 2014 at 07:28:01PM +0200, Javier Martinez Canillas wrote: Hello Dmitry, On 08/25/2014 07:05 PM, Dmitry Torokhov wrote: Patches #1, #2, #6 and #7 do not depend of others so they can be merged independently but patches #3, #4 and #5 have to be merged in that specific order since they depend on the previous one. #7 does not apply to my tree (I guess it depends on the 1st batch which I expect will go through MFD tree?). Maybe you could rebase it on top of my next so it can be applied sooner? Or it really needs parts of patchset #1? The first batch sent by Doug did indeed touch this driver and the patches were merged through the MFD tree for 3.17 as you said. I see that your next branch is based on 3.16-rc6 and that is why it does not apply cleanly. I guess you will rebase your next branch for 3.18 on top of 3.17-rc1 anyways which will fix this issue? If not please let me know and I can of course re-spin the patch so it applies cleanly on top of 3.16-rc6. I normally merge with mainline around -rc3 so please ping me around that time if you do not see the patch in my tree. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
