[PATCH v2 0/7] Add cros_ec changes for newer boards

[Doug Anderson]

Lee,

On Mon, Apr 28, 2014 at 2:19 AM, Lee Jones <lee.jones at linaro.org> wrote:
> [...]
>
>> >>> Need to wait for the ARM, DT and I2C guys to review, at which point
>> >>> I'll be happy to take in and supply a branch for them to pull from if
>> >>> required. If there are no _true_ dependencies and the MFD changes can
>> >>> be added independently without fear of build breakages, let me know
>> >>> and I'll apply them separately.
>> >>
>> >> I believe there aren't direct dependencies between the patches. So, the
>> >> MFD patches can be applied to the MFD tree and the DT patch applied to
>> >> the Tegra tree. I'm simply waiting for the MFD patches to be applied
>> >> before applying the DT patch so that I know the DT binding definition is
>> >> fully accepted before applying a patch that uses it.
>> >
>> > All of the MFD patches are safe to apply and in pretty much arbitrary
>> > order.  The strong dependencies in the chain are:
>> >
>> > * We need patch #5 (mfd: cros_ec: Sync to the latest
>> > cros_ec_commands.h from EC sources) before the i2c tunnel can compile.
>> >
>> > * As Stephen says, he shouldn't apply the device tree until we're
>> > confident that the bindings are right.  However there's no strong
>> > dependency otherwise.
>> >
>> > * Patches #1 #2 and #3 are simply reliability fixes.  Those could land
>> > at any point in time and will improve other users of cros_ec_spi (like
>> > the keyboard on tegra124-venice2).
>> >
>> > * Patch #4 can apply any time with no issues.  Without it large i2c
>> > tunnel transfers won't work, but that's not a terrible problem (all
>> > normal transfers are small).
>>
>> Patch #5 (latest ec commands) can also apply at any time with no
>> issues, but it's needed for patch #6 (the tunnel) to compile.
>>
>> All that being said, I'd request that you merge patches #1-#5 as soon
>> as you can and make sure you can provide a way that Wolfram can pull
>> them (or at least patch #5) into his i2c tree to keep them applying
>> when he is ready to land #6.
>
> Very well. So if I can obtain Wolfram's Ack, I can apply the MFD
> changes along with patch #6 and supply him with a branch.

Can you explain the reason to wait for Wolfram's Ack before applying
#1 - #5?  I would think:

1. Create a topic branch.
2. Apply patches 1-5 to the topic branch
3. Merge the topic branch to your for-next branch

When Wolfram wants to take patch #6, he can either:
A. Pull your topic branch
B. If it's been long enough, patches will already be in ToT and no extra work.

If I understand correctly, using a topic branch and doing merges /
pulls means that you can provide Wolfram with stable git hashes when
he needs them and there will be no merge conflicts.

Patches #1 - #5 are bonafide bugfixes irrespective of the i2c tunnel.

-Doug