Add cros_ec changes for newer boards
Get series with b4
b4 am 20140429082146.GE29462@lee--X1Versions newest first · linked by author and title
- v2 Latest posting 2/20 of 7 patches 0 repliesNew
- v2 posting 1/20 of 7 patches 0 repliesSuperseded
Patches in v2 posting 2/2 No applies recorded yet
None of the 7 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [PATCH v2 0/7] Add cros_ec changes for newer boards
Quoted 48 lines
Quoted 33 lines
Quoted 33 lines
Quoted 22 lines
Quoted 11 lines
Quoted 5 lines
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 latestcros_ec_commands.hfrom 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.
Quoted 7 lines
* 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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 7 lines
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.
I don't use TBs for MFD yet, as I've never seen the need. The current WoW is to only create extra branches when I have patch{es, sets} to share. If I start using a more TB focused methodology it will be insinuated that the branches are stable - I like the fact that this is _not_ the case. Currently I am able to rebase, rework and reorder the repo as and when I see fit, and do regularly. Except the IBs of course.
Quoted 1 line
Patches #1 - #5 are bonafide bugfixes irrespective of the i2c tunnel.
I only want to create an IB if I know it's going to be used, else I'd prefer the patches remain transient. Why are you so keen to rush into having these patches applied? They _will_ make it into v3.15, whether they are applied immediately or after a length of time (in the case that Wolfram does not respond).
Signature · 4 lines
Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog