Hi Linus,
Here is the second batch of arm-soc changes for this merge window. As Arnd
mentioned with the first cover letter, most of these either had external
dependencies that have now been pulled in, or just needed a bit more
linux-next bake time due to getting picked up close to the 3.3 release.
There are 128 non-merge patches, with a total diffstat of:
346 files changed, 10790 insertions(+), 2792 deletions(-)
So, while there's been some good cleanups especially in the first branch,
there's been a net addition of code:
* New SoC family support for Samsung EXYNOS5250: clock tables, driver
updates, etc means net gain in code.
* Added device tree conversions. Once we start to sunset non-device tree
boards on the enabled platforms, we should see payback in code removal.
* Common clock framework. As SoCs get converted over to the framework,
we should see more code removal from this as well.
There are a handful of merge conflicts on the branches, nothing that
should be too messy to sort out. I've described each conflict in the
corresponding pull request, including how we've resolved them in our
for-next branch.
Thanks,
-Olof
On 03/28/2012 02:13 AM, Olof Johansson wrote:
Hi Linus,
Here is the second batch of arm-soc changes for this merge window. As Arnd
mentioned with the first cover letter, most of these either had external
dependencies that have now been pulled in, or just needed a bit more
linux-next bake time due to getting picked up close to the 3.3 release.
There are 128 non-merge patches, with a total diffstat of:
346 files changed, 10790 insertions(+), 2792 deletions(-)
So, while there's been some good cleanups especially in the first branch,
there's been a net addition of code:
* New SoC family support for Samsung EXYNOS5250: clock tables, driver
updates, etc means net gain in code.
* Added device tree conversions. Once we start to sunset non-device tree
boards on the enabled platforms, we should see payback in code removal.
* Common clock framework. As SoCs get converted over to the framework,
we should see more code removal from this as well.
There are a handful of merge conflicts on the branches, nothing that
should be too messy to sort out. I've described each conflict in the
corresponding pull request, including how we've resolved them in our
for-next branch.
Why isn't lakml getting copied on emails 1-5? The same thing happened
with Arnd's pull request. Are they getting hung up for moderator approval?
Rob
On Wednesday 28 March 2012, Rob Herring wrote:
On 03/28/2012 02:13 AM, Olof Johansson wrote:
quoted
There are a handful of merge conflicts on the branches, nothing that
should be too messy to sort out. I've described each conflict in the
corresponding pull request, including how we've resolved them in our
for-next branch.
Why isn't lakml getting copied on emails 1-5? The same thing happened
with Arnd's pull request. Are they getting hung up for moderator approval?
For some reason, the mailing list rejected the emails with 'suspicious header'
warnings, but did not list which headers were suspicious. I think I've
had this problem before and solved it, but don't remember the solution
any more now. linux-kernel took the emails though.
Arnd