Hi Mark -
I have some small practical questions about LSK. I was able to make a tree with our linux-linaro-core-tracking@v3.10 LT patches on LSK basis work well (so far).
I found this repo (it needs its ./description updating)
https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git%3Ba=summary
1) There seems to be two choices, linux-linaro-lsk and linux-linaro-lsk-android.
I chose the android one, I assume it has the same "androidization" series on top that linux-linaro-core-tracking used at 3.10? Are there any other differences?
2) I saw the vexpress integration stuff from ARM LT was included already which is good, is there a wiki page (or README.html or the gitweb is also good) explaining the composition?
3) In our LT tree we patch mainline to remove all warnings coming with our defconfig. Then if we see any warnings coming, we know it's our fault and we need to go fix it. Are you interested in taking a similar approach?
4) Maybe this is too much thinking ahead, but shouldn't these lsk branches be versioned, like linux-linaro-lsk-3.10? Otherwise when the next lsk version is announced there'll be a problem.
-Andy
On 5 August 2013 10:45, Andy Green andy.green@linaro.org wrote:
Hi Mark -
I have some small practical questions about LSK. I was able to make a tree with our linux-linaro-core-tracking@v3.10 LT patches on LSK basis work well (so far).
I found this repo (it needs its ./description updating)
https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git%3Ba=summary
- There seems to be two choices, linux-linaro-lsk and linux-linaro-lsk-android.
I chose the android one, I assume it has the same "androidization" series on top that linux-linaro-core-tracking used at 3.10? Are there any other differences?
- I saw the vexpress integration stuff from ARM LT was included
already which is good, is there a wiki page (or README.html or the gitweb is also good) explaining the composition?
- In our LT tree we patch mainline to remove all warnings coming with
our defconfig. Then if we see any warnings coming, we know it's our fault and we need to go fix it. Are you interested in taking a similar approach?
- Maybe this is too much thinking ahead, but shouldn't these lsk
branches be versioned, like linux-linaro-lsk-3.10? Otherwise when the next lsk version is announced there'll be a problem.
5) Gator bits don't seem to be in there, presumably that's something ARM would like to see in there (it appears in llct)
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0482a/BABEJAA... https://git.linaro.org/gitweb?p=landing-teams/working/arm/kernel.git%3Ba=sho...
-Andy
-Andy
On Mon, 2013-08-05 at 16:43 +0800, Andy Green wrote:
On 5 August 2013 10:45, Andy Green andy.green@linaro.org wrote:
Hi Mark -
I have some small practical questions about LSK. I was able to make a tree with our linux-linaro-core-tracking@v3.10 LT patches on LSK basis work well (so far).
I found this repo (it needs its ./description updating)
https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git%3Ba=summary
- There seems to be two choices, linux-linaro-lsk and linux-linaro-lsk-android.
I chose the android one, I assume it has the same "androidization" series on top that linux-linaro-core-tracking used at 3.10? Are there any other differences?
- I saw the vexpress integration stuff from ARM LT was included
already which is good, is there a wiki page (or README.html or the gitweb is also good) explaining the composition?
- In our LT tree we patch mainline to remove all warnings coming with
our defconfig. Then if we see any warnings coming, we know it's our fault and we need to go fix it. Are you interested in taking a similar approach?
- Maybe this is too much thinking ahead, but shouldn't these lsk
branches be versioned, like linux-linaro-lsk-3.10? Otherwise when the next lsk version is announced there'll be a problem.
- Gator bits don't seem to be in there, presumably that's something
ARM would like to see in there (it appears in llct)
Yes, and I believe someone was raising a card to get it added, and I assume the 'stable' kernel will need updating for each new release of DS-5 as people will want the latest version.
Of course, there isn't a great deal of reason to have it in the kernel tree apart from letting you build it into the kernel to avoid having to deploy is separately when you rebuild a kernel binary.
Gator is available from ARM as a tarball and from the Linaro git git://git.linaro.org/arm/ds5/gator.git. Linaro Android builds use that repo so you don't need it in the kernel tree for that and it can be installed on Linaro Ubuntu images with: apt-get install gator-daemon gator-module-dkms
On 5 August 2013 10:11, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Mon, 2013-08-05 at 16:43 +0800, Andy Green wrote:
- Gator bits don't seem to be in there, presumably that's something
ARM would like to see in there (it appears in llct)
Yes, and I believe someone was raising a card to get it added, and I assume the 'stable' kernel will need updating for each new release of DS-5 as people will want the latest version.
This is the first I've heard of this, could whoever this is please talk to me about it?
Hi, On 5 August 2013 12:44, Mark Brown broonie@linaro.org wrote:
On 5 August 2013 10:11, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Mon, 2013-08-05 at 16:43 +0800, Andy Green wrote:
- Gator bits don't seem to be in there, presumably that's something
ARM would like to see in there (it appears in llct)
Yes, and I believe someone was raising a card to get it added, and I assume the 'stable' kernel will need updating for each new release of DS-5 as people will want the latest version.
This is the first I've heard of this, could whoever this is please talk to me about it?
Do we have a plan for adding gator to LSK now? I have a request to support gator on LSK based image, and I'd prefer not to add the module from outside the kernel.
Riku
On 16 September 2013 11:48, Riku Voipio riku.voipio@linaro.org wrote:
Do we have a plan for adding gator to LSK now? I have a request to support gator on LSK based image, and I'd prefer not to add the module from outside the kernel.
No, there's a card in process but it's not been approved yet.
On Mon, 2013-08-05 at 10:45 +0800, Andy Green wrote:
- I saw the vexpress integration stuff from ARM LT was included
already which is good, is there a wiki page (or README.html or the gitweb is also good) explaining the composition?
The vexpress branch is basicall the same as what is in linux-linaro for the 13.07 release. I always merge my topics one at a time with --no-ff so it's easier to see how a branch is composed. A brief one line summary for each is...
tracking-armlt-config vexpress config fragments
tracking-armlt-rtsm Device-tree updates for RTSM
tracking-armlt-ve-updates Miscellaneous fixes for vexpress.
tracking-armlt-hdlcd HDCLCD driver (TC2's video hardware).
tracking-armlt-clcd Modifications to CLCD driver to work with device-tree, needed for fast models.
tracking-armlt-misc-fixes Miscellaneous fixes useful for vexpress and TC2 but not necessarily to vexpress specific code.
tracking-armlt-tc2-dt TC2 device-tree updates.
tracking-armlt-mcpm Tweaks to the MCPM code which aren't upstream.
tracking-armlt-cci CCI driver and CCI PMU patches.
tracking-armlt-spc vexpress Serial Power Controller (SPC) present in ARM Versatile Express TC2 core tiles.
tracking-armlt-psci PSCI changes to enable run time selection of PSCI.
tracking-armlt-dcscb Tweaks to the DCSCB code (RTSM's cluster control) which aren't upstream.
tracking-armlt-tc2-pm TC2 PM functions and big.LITTLE cpuidle driver.
tracking-armlt-tc2-psci Updates TC2 PM functions to use PSCI. This topic is stacked on top of -tc2-pm as it modifies it.
tracking-armlt-tc2-cpufreq big.LITTLE cpufreq driver for vexpress.
tracking-armlt-iks-cpufreq IKS cpufreq driver.
The latter is probably not vexpress specific, I just inherited it because no-one else was handling it.
On 5 August 2013 16:58, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Mon, 2013-08-05 at 10:45 +0800, Andy Green wrote:
- I saw the vexpress integration stuff from ARM LT was included
already which is good, is there a wiki page (or README.html or the gitweb is also good) explaining the composition?
The vexpress branch is basicall the same as what is in linux-linaro for the 13.07 release. I always merge my topics one at a time with --no-ff so it's easier to see how a branch is composed. A brief one line summary
Right, it's much clearer that way. I was really asking about composition of what's in LSK, since for your and Andrey's tracking / rebase + merge branches I can look at the log and see. But LSK will have a linear history, it's already hard to see what's in there without log --graph.
However this is very useful documentation -->
for each is...
tracking-armlt-config vexpress config fragments
tracking-armlt-rtsm Device-tree updates for RTSM
tracking-armlt-ve-updates Miscellaneous fixes for vexpress.
tracking-armlt-hdlcd HDCLCD driver (TC2's video hardware).
tracking-armlt-clcd Modifications to CLCD driver to work with device-tree, needed for fast models.
tracking-armlt-misc-fixes Miscellaneous fixes useful for vexpress and TC2 but not necessarily to vexpress specific code.
tracking-armlt-tc2-dt TC2 device-tree updates.
tracking-armlt-mcpm Tweaks to the MCPM code which aren't upstream.
tracking-armlt-cci CCI driver and CCI PMU patches.
We started using that the other day trying to track down a nasty bug, I didn't even know we got it from vexpress ^^
The whole list is good things to have I just wonder how ongoing updates will be handled for backport. For example at some point "Tweaks to the MCPM code which aren't upstream." will go upstream and probably be a bit different by then, someone should "revert" (it may not be that clean since other patches may have meddled) the old one in lsk and "replace" with the upstream patches. Mark's watching out for that, or you are for the trees you merged that went into LSK, or what's the plan?
-Andy
tracking-armlt-spc vexpress Serial Power Controller (SPC) present in ARM Versatile Express TC2 core tiles.
tracking-armlt-psci PSCI changes to enable run time selection of PSCI.
tracking-armlt-dcscb Tweaks to the DCSCB code (RTSM's cluster control) which aren't upstream.
tracking-armlt-tc2-pm TC2 PM functions and big.LITTLE cpuidle driver.
tracking-armlt-tc2-psci Updates TC2 PM functions to use PSCI. This topic is stacked on top of -tc2-pm as it modifies it.
tracking-armlt-tc2-cpufreq big.LITTLE cpufreq driver for vexpress.
tracking-armlt-iks-cpufreq IKS cpufreq driver.
The latter is probably not vexpress specific, I just inherited it because no-one else was handling it.
-- Tixy
On Mon, 2013-08-05 at 17:13 +0800, Andy Green wrote:
On 5 August 2013 16:58, Jon Medhurst (Tixy) tixy@linaro.org wrote:
tracking-armlt-cci CCI driver and CCI PMU patches.
We started using that the other day trying to track down a nasty bug, I didn't even know we got it from vexpress ^^
The driver is now in 3.11, but the PMU patches aren't.
The whole list is good things to have I just wonder how ongoing updates will be handled for backport. For example at some point "Tweaks to the MCPM code which aren't upstream." will go upstream and probably be a bit different by then, someone should "revert" (it may not be that clean since other patches may have meddled) the old one in lsk and "replace" with the upstream patches. Mark's watching out for that, or you are for the trees you merged that went into LSK, or what's the plan?
Plan? There's no plan that I know of.
On 5 August 2013 10:44, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Mon, 2013-08-05 at 17:13 +0800, Andy Green wrote:
The whole list is good things to have I just wonder how ongoing updates will be handled for backport. For example at some point "Tweaks to the MCPM code which aren't upstream." will go upstream and probably be a bit different by then, someone should "revert" (it may not be that clean since other patches may have meddled) the old one in lsk and "replace" with the upstream patches. Mark's watching out for that, or you are for the trees you merged that went into LSK, or what's the plan?
Plan? There's no plan that I know of.
As was mentioned on linaro-kernel the plan is that you should be sending me incremental updates as needed. I'm not monitoring everything that goes upstream, especially in this case where I didn't get a breakdown of what went in there or topic branches for the vexpress enablement so I've very little visibility of what's there.
On Mon, 2013-08-05 at 10:53 +0100, Mark Brown wrote:
On 5 August 2013 10:44, Jon Medhurst (Tixy) tixy@linaro.org wrote: On Mon, 2013-08-05 at 17:13 +0800, Andy Green wrote: > The whole list is good things to have I just wonder how ongoing > updates will be handled for backport. For example at some point > "Tweaks to the MCPM code which aren't upstream." will go upstream and > probably be a bit different by then, someone should "revert" (it may > not be that clean since other patches may have meddled) the old one in > lsk and "replace" with the upstream patches. Mark's watching out for > that, or you are for the trees you merged that went into LSK, or > what's the plan? Plan? There's no plan that I know of.
As was mentioned on linaro-kernel the plan is that you should be sending me incremental updates as needed.
But who decides what's needed? If what is in 3.10 works, why backport a different version? And I hadn't planned on spending any time on backporting new versions or fixes.
On 5 August 2013 18:00, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Mon, 2013-08-05 at 10:53 +0100, Mark Brown wrote:
On 5 August 2013 10:44, Jon Medhurst (Tixy) tixy@linaro.org wrote: On Mon, 2013-08-05 at 17:13 +0800, Andy Green wrote:
> The whole list is good things to have I just wonder how ongoing > updates will be handled for backport. For example at some point > "Tweaks to the MCPM code which aren't upstream." will go upstream and > probably be a bit different by then, someone should "revert" (it may > not be that clean since other patches may have meddled) the old one in > lsk and "replace" with the upstream patches. Mark's watching out for > that, or you are for the trees you merged that went into LSK, or > what's the plan? Plan? There's no plan that I know of.As was mentioned on linaro-kernel the plan is that you should be sending me incremental updates as needed.
But who decides what's needed? If what is in 3.10 works, why backport a different version? And I hadn't planned on spending any time on backporting new versions or fixes.
Often there are improvements from upstream comment inbetween the last private drop of something and it appearing upstream. That can just be style or it can be better error handling or covering cases that weren't originally obvious. You won't literally always need to backport the changes if it's removing a comment or something but generally someone's going to at least have to eyeball the version that went upstream and check nothing nasty got fixed before ignoring it.
More to the point there may need to be some kind of "traceability" list for what fed LSK like the merged topics list you sent, and if Mark expects someone to monitor those then an "owner" associated with that as well (maybe you can pass the buck up to the component merge branch author). Otherwise with it being a "long term history branch" pretty soon there will be so many patches piled on you'll have to do git diff v3.10 --stat to try understand what's actually in there.
Somebody needs to follow the status of the contribution branch content in terms of it went upstream now or it got rejected or it was redone etc.
There won't be that many topic branches overall in LSK, so it should be something that can stay under control if it's understood it needs to be under control.
-Andy
On 5 August 2013 11:00, Jon Medhurst (Tixy) tixy@linaro.org wrote:
As was mentioned on linaro-kernel the plan is that you should be
sending me incremental updates as needed.
But who decides what's needed? If what is in 3.10 works, why backport a different version? And I hadn't planned on spending any time on backporting new versions or fixes.
For things that are out of tree the advertised policy is that we should be tracking the upstream submissions as far as possible in order to avoid having a "special" version of the code in the LSK. There's two broad reasons for keeping the backport in sync with the upstream version (if there is an upstream version).
One is that if there are changes being made upstream they are hopefully being made for some reason and often those reasons will also apply to the backported version, bug fixes being the most obvious example here.
The other is that if we track what's going on development wise then it reduces the effort required when we do need to do the backporting of the bug fixes or ask people working on the upstream code for help resolving issues. This is the flip side of the problem that frequently exists with people doing development on their production releases and never syncing them with upstream, the benefits go both ways here.
On 5 August 2013 03:45, Andy Green andy.green@linaro.org wrote:
- There seems to be two choices, linux-linaro-lsk and
linux-linaro-lsk-android.
I chose the android one, I assume it has the same "androidization" series on top that linux-linaro-core-tracking used at 3.10? Are there any other differences?
There are some patches to improve the performance of the interactive scheduler in there as well. Currently we didn't take John's branch in order to make it easier to track the Google stuff while we're preparing for release, that will get filtered in sometime this week.
There may be other stuff lurking in linux-linaro that I'm not aware of, everything is supposed to be individually selected for backport.
- In our LT tree we patch mainline to remove all warnings coming with
our defconfig. Then if we see any warnings coming, we know it's our fault and we need to go fix it. Are you interested in taking a similar approach?
We will take suitably non-invasive warning fixes and obviously any actual bug fixes that are fixed in the upstream LTS but we won't actively go looking for warnings in anything that's not built for testing of LSK ourselves. There is no commitment to making things in the underlying kernel warning free.
- Maybe this is too much thinking ahead, but shouldn't these lsk
branches be versioned, like linux-linaro-lsk-3.10? Otherwise when the next lsk version is announced there'll be a problem.
This is what I inherited, we'd certainly start versioning things when there's more than one LSK around but having a "this is the default version" pointer does seem useful. I was intending to add versioned branches as part of the official release (which should be 13.08 now Greg's announced v3.10 as a LTS).
On 5 August 2013 18:16, Mark Brown broonie@linaro.org wrote:
On 5 August 2013 03:45, Andy Green andy.green@linaro.org wrote:
- There seems to be two choices, linux-linaro-lsk and
linux-linaro-lsk-android.
I chose the android one, I assume it has the same "androidization" series on top that linux-linaro-core-tracking used at 3.10? Are there any other differences?
There are some patches to improve the performance of the interactive scheduler in there as well. Currently we didn't take John's branch in order to make it easier to track the Google stuff while we're preparing for release, that will get filtered in sometime this week.
I see, thanks.
There may be other stuff lurking in linux-linaro that I'm not aware of, everything is supposed to be individually selected for backport.
Literally linux-linaro I'm not sure is useful for anything, the tree LTs are basing on is linux-linaro-core-tracking.
It's composed by rebase and then merges, so it's easy to see what's in there from a quick git log.
https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git%3Ba=shortlo...
For tracking, we rebase our BSP patches on this every rc and get all the latest nice things like IKS and HMP coming in our tree with no drama.
For v3.10 what I've done is switch the basis from the v3.10 version of llct to your tree, and that went easily too.
- In our LT tree we patch mainline to remove all warnings coming with
our defconfig. Then if we see any warnings coming, we know it's our fault and we need to go fix it. Are you interested in taking a similar approach?
We will take suitably non-invasive warning fixes and obviously any actual bug fixes that are fixed in the upstream LTS but we won't actively go looking for warnings in anything that's not built for testing of LSK ourselves. There is no commitment to making things in the underlying kernel warning free.
Sounds reasonable.... attached is our current patch for your consideration. There's a permanent #warning about an unwind tables TODO this also knocks out the others are actual problems.
- Maybe this is too much thinking ahead, but shouldn't these lsk
branches be versioned, like linux-linaro-lsk-3.10? Otherwise when the next lsk version is announced there'll be a problem.
This is what I inherited, we'd certainly start versioning things when there's more than one LSK around but having a "this is the default version" pointer does seem useful. I was intending to add versioned branches as part of the official release (which should be 13.08 now Greg's announced v3.10 as a LTS).
If we start doing it shortly it's fine. Otherwise people who want 3.10-specific one will have no choice but to point at the "latest" one if that's all there is, and that will not always be 3.10. Having the default one mirror the latest versioned one sounds like the best of both worlds.
-Andy
On Mon, Aug 05, 2013 at 06:42:33PM +0800, Andy Green wrote:
On 5 August 2013 18:16, Mark Brown broonie@linaro.org wrote:
There may be other stuff lurking in linux-linaro that I'm not aware of, everything is supposed to be individually selected for backport.
Literally linux-linaro I'm not sure is useful for anything, the tree LTs are basing on is linux-linaro-core-tracking.
It's composed by rebase and then merges, so it's easy to see what's in there from a quick git log.
That doesn't help with understanding why any of it is there or what it's for.
Sounds reasonable.... attached is our current patch for your consideration. There's a permanent #warning about an unwind tables TODO this also knocks out the others are actual problems.
Please split this up into proper patches, and of course you should be submitting any fixes upstream if they're still present - if you're doing this sort of warning cleanup work it's going to be useful upstream too. I had a quick glance through and:
- Things like just assigning a value to variables at declaration are worrying since that just shuts up the flow analysis warnings even if they're actually pointing out a genuine missed code path.
- The regmap change isn't something that I've seen upstream...
- For printf() warnings consider changing the printf() format specifier to be accurate rather than casting.
On 5 August 2013 18:59, Mark Brown broonie@kernel.org wrote:
On Mon, Aug 05, 2013 at 06:42:33PM +0800, Andy Green wrote:
On 5 August 2013 18:16, Mark Brown broonie@linaro.org wrote:
There may be other stuff lurking in linux-linaro that I'm not aware of, everything is supposed to be individually selected for backport.
Literally linux-linaro I'm not sure is useful for anything, the tree LTs are basing on is linux-linaro-core-tracking.
It's composed by rebase and then merges, so it's easy to see what's in there from a quick git log.
That doesn't help with understanding why any of it is there or what it's for.
Andrey is here hopefully he can do a Tixy-style breakdown.
Sounds reasonable.... attached is our current patch for your consideration. There's a permanent #warning about an unwind tables TODO this also knocks out the others are actual problems.
Please split this up into proper patches, and of course you should be submitting any fixes upstream if they're still present - if you're doing this sort of warning cleanup work it's going to be useful upstream too. I had a quick glance through and:
These are only applied on lsk and llct, I don't actually know where the code patched came from but I think they're all mainline. I'll check it out later.
- Things like just assigning a value to variables at declaration are worrying since that just shuts up the flow analysis warnings even if they're actually pointing out a genuine missed code path.
In this case it's okay, that var is written via a pointer arg to another call, but the call either returns an err or fills it in. The value is only used on non-error path. It's just keeping the compiler happy.
- The regmap change isn't something that I've seen upstream...
If you mean where did the original come from
commit 5a08d15602987bbdff3407d7645f95b7a70f1a6f Author: Stephen Warren swarren@nvidia.com Date: Wed Mar 20 17:02:02 2013 -0600
regmap: don't corrupt work buffer in _regmap_raw_write()
- For printf() warnings consider changing the printf() format specifier to be accurate rather than casting.
Yes fair enough.
-Andy
On Mon, Aug 05, 2013 at 07:37:10PM +0800, Andy Green wrote:
On 5 August 2013 18:59, Mark Brown broonie@kernel.org wrote:
- The regmap change isn't something that I've seen upstream...
If you mean where did the original come from
I mean I haven't seen that warning that I'm aware of.
commit 5a08d15602987bbdff3407d7645f95b7a70f1a6f Author: Stephen Warren swarren@nvidia.com Date: Wed Mar 20 17:02:02 2013 -0600
regmap: don't corrupt work buffer in _regmap_raw_write()
Note that the above change is part of v3.10...
On 5 August 2013 22:11, Mark Brown broonie@kernel.org wrote:
On Mon, Aug 05, 2013 at 07:37:10PM +0800, Andy Green wrote:
On 5 August 2013 18:59, Mark Brown broonie@kernel.org wrote:
- The regmap change isn't something that I've seen upstream...
If you mean where did the original come from
I mean I haven't seen that warning that I'm aware of.
commit 5a08d15602987bbdff3407d7645f95b7a70f1a6f Author: Stephen Warren swarren@nvidia.com Date: Wed Mar 20 17:02:02 2013 -0600
regmap: don't corrupt work buffer in _regmap_raw_write()Note that the above change is part of v3.10...
I know, it's just unclear what you were saying about "the regmap change isn't something that I've seen upstream..."
I went through and split out the fixes after examining each one.
1) warning elimination: arm: silence THUMB2 no unwind warning
I think RMK wants it to blow warnings, the issue is there's no frame context if you build THUMB2 (which we are). In Kconfig
# RMK wants arm kernels compiled with frame pointers or stack unwinding. # If you know what you are doing and are willing to live without stack # traces, you can get a slightly smaller kernel by setting this option to # n, but then RMK will have to kill you ;). config FRAME_POINTER bool depends on !THUMB2_KERNEL
so I doubt he'll accept a patch silencing it. For me, it's a pointless warning and for lsk fixed at 3.10 it's also pointless IMO.
2) warning-elimination: android: binder
This seems to be a problem with a patch already upstream
3) warning-elimination: androidization: mm
Problem coming from Androidization patches
4) warning-elimination: ata: ata_hpa_resize default assignment
Issue is upstream but I can't reproduce original compiler warning
5) warning-elimination: ion: use size_t-specific format
Introduced in Androidization
6) warning-elimination: nobody uses cci_pmu_destroy
Presumably coming from the CCI stuff Tixy pulled in
7) warning-elimination: regmap: cast pointer arg from int
This seems to be a genuine issue of passing an int to a function wanting a const void *. However I can't reproduce the warning.
8) warning-elimination: usb: dwc3
This only made problems if you have CONFIG_PM but not CONFIG_SUSPEND, dunno if people care or not.
So 3 and 5 are out-of-mainline Androidizaton issues.
6 only exists on ARM LT tree -> llct / lsk and need to be dealt with here.
1 4, and 8 I doubt anyone will buy upstream, but you should still consider 1. 4 can't be demonstrated to be a problem right now (although it has been...) 8 we turned on SUSPEND ourselves since it was a problem.
2 is a problem from mainline.
7 is your department.
-Andy
On 08/05/2013 05:24 PM, Andy Green wrote:
- warning-elimination: android: binder
This seems to be a problem with a patch already upstream
- warning-elimination: androidization: mm
Problem coming from Androidization patches
[snip]
- warning-elimination: ion: use size_t-specific format
Introduced in Androidization
Thanks Andy!
I've applied these three to the linaro-fixes/experimental/android-3.10 branch.
Are you planning on sending #2 above on to lkml/Greg?
thanks -john
On 6 August 2013 11:03, John Stultz john.stultz@linaro.org wrote:
On 08/05/2013 05:24 PM, Andy Green wrote:
- warning-elimination: android: binder
This seems to be a problem with a patch already upstream
- warning-elimination: androidization: mm
Problem coming from Androidization patches
[snip]
- warning-elimination: ion: use size_t-specific format
Introduced in Androidization
Thanks Andy!
I've applied these three to the linaro-fixes/experimental/android-3.10 branch.
Thanks.
Are you planning on sending #2 above on to lkml/Greg?
Yes, you and Mark are on cc.
-Andy
thanks -john
On Tue, Aug 06, 2013 at 08:24:52AM +0800, Andy Green wrote:
I went through and split out the fixes after examining each one.
Please submit things normally - attachments are non-standard and difficult to work with (both from the point of view of applying and from the point of view of workflow) and if you don't mention them they're not always terribly visible either. I didn't actually notice there was anything here first time around...
If you do send attachments keep them as text/plain so that things like quoting in replies work.
- warning-elimination: ata: ata_hpa_resize default assignment
Issue is upstream but I can't reproduce original compiler warning
If the compiler figures it out we can probably drop this then. If it is still needed then it should be being submitted upstream.
- warning-elimination: nobody uses cci_pmu_destroy
Presumably coming from the CCI stuff Tixy pulled in
I'll apply this but please do send it to the ARM LT, we should be fixing this stuff in linux-linaro too.
- warning-elimination: regmap: cast pointer arg from int
This seems to be a genuine issue of passing an int to a function wanting a const void *. However I can't reproduce the warning.
This looks like you had a compiler bug or were carrying some other breakage; val is a pointer so we're just doing pointer arithmetic here, there's no casting needed and if there were the cast you're adding should be on val not on the final result.
- warning-elimination: usb: dwc3
This only made problems if you have CONFIG_PM but not CONFIG_SUSPEND, dunno if people care or not.
This should certainly be addressed upstream, please submit it.
1 4, and 8 I doubt anyone will buy upstream, but you should still consider 1. 4 can't be demonstrated to be a problem right now (although it has been...) 8 we turned on SUSPEND ourselves since it was a problem.
Please use descriptive names for things rather than just numbers, it makes everything more legible. Except for the THUMB thing I don't see why any of these shouldn't be upstream - what makes you believe that there would be a problem?
On 6 August 2013 20:47, Mark Brown broonie@kernel.org wrote:
On Tue, Aug 06, 2013 at 08:24:52AM +0800, Andy Green wrote:
I went through and split out the fixes after examining each one.
Please submit things normally - attachments are non-standard and difficult to work with (both from the point of view of applying and from the point of view of workflow) and if you don't mention them they're not always terribly visible either. I didn't actually notice there was anything here first time around...
I wonder why Google has an attachment button.
If you do send attachments keep them as text/plain so that things like quoting in replies work.
Bad google.
- warning-elimination: ata: ata_hpa_resize default assignment
Issue is upstream but I can't reproduce original compiler warning
If the compiler figures it out we can probably drop this then. If it is still needed then it should be being submitted upstream.
Yes it's strange though I did not have a stroke and start editing code randomly, this was generating an error in the recent past.
- warning-elimination: nobody uses cci_pmu_destroy
Presumably coming from the CCI stuff Tixy pulled in
I'll apply this but please do send it to the ARM LT, we should be fixing this stuff in linux-linaro too.
Tixy's on the list and hopefully able to process these newfangled attachments with his steampunk email client.
- warning-elimination: regmap: cast pointer arg from int
This seems to be a genuine issue of passing an int to a function wanting a const void *. However I can't reproduce the warning.
This looks like you had a compiler bug or were carrying some other breakage; val is a pointer so we're just doing pointer arithmetic here, there's no casting needed and if there were the cast you're adding should be on val not on the final result.
At the time it generated an warning it silenced it.
I can see it's reasonable to ignore it when it isn't any longer, so fair enough.
I have not updated my toolchain since March, so whatever changed is in the larger set of code, eg, headers, there's definitely something curious about the fixes that still apply but no longer genenrate the warning that got them fixed when the fix is removed.
I noticed on 3.11-rc3 there's a make option W=? that I didn't see before, don't know when it was introduced. Maybe there has been some fiddling with gcc commandline at make level that impacts what's reported. As I say the toolchain is no different only thing that changed is the code as a whole.
- warning-elimination: usb: dwc3
This only made problems if you have CONFIG_PM but not CONFIG_SUSPEND, dunno if people care or not.
This should certainly be addressed upstream, please submit it.
1 4, and 8 I doubt anyone will buy upstream, but you should still consider 1. 4 can't be demonstrated to be a problem right now (although it has been...) 8 we turned on SUSPEND ourselves since it was a problem.
Please use descriptive names for things rather than just numbers, it makes everything more legible. Except for the THUMB thing I don't see why any of these shouldn't be upstream - what makes you believe that there would be a problem?
Hm you know the dynamic of people submitting things for your critique is not the only conversational mode that's possible, has that crossed your mind?
-Andy
On Tue, 2013-08-06 at 21:12 +0800, Andy Green wrote:
On 6 August 2013 20:47, Mark Brown broonie@kernel.org wrote:
On Tue, Aug 06, 2013 at 08:24:52AM +0800, Andy Green wrote:
- warning-elimination: nobody uses cci_pmu_destroy
Presumably coming from the CCI stuff Tixy pulled in
I'll apply this but please do send it to the ARM LT, we should be fixing this stuff in linux-linaro too.
Tixy's on the list and hopefully able to process these newfangled attachments with his steampunk email client.
I'd mostly stopped reading this thread but somehow managed to notice this. A proper mailed patch to the list, or a quick mail to me would have been more obvious ;-) I went back to the the original mail and scrolled down to the bottom to find the attachments in my steampunk email client, and I'll add that to my CCI topic branch.
The PMU support is a Frankenstein creation cobbled together from previous patches and intended to keep CCI support in Gator working. There are newer patches on the upstream lists which may break things again, but I've sorta stopped pro-actively trying to keep my branches up-to-date with latest work, as I don't seem to have the time any more and it seems a forlorn task. Especially as a lot of it seems under constant churn as people ague about how things should look. Best to just wait for it to turn up in mainline and deal with it them.
On Aug 6, 2013 11:06 PM, "Jon Medhurst (Tixy)" tixy@linaro.org wrote:
On Tue, 2013-08-06 at 21:12 +0800, Andy Green wrote:
On 6 August 2013 20:47, Mark Brown broonie@kernel.org wrote:
On Tue, Aug 06, 2013 at 08:24:52AM +0800, Andy Green wrote:
- warning-elimination: nobody uses cci_pmu_destroy
Presumably coming from the CCI stuff Tixy pulled in
I'll apply this but please do send it to the ARM LT, we should be
fixing
this stuff in linux-linaro too.
Tixy's on the list and hopefully able to process these newfangled attachments with his steampunk email client.
I'd mostly stopped reading this thread but somehow managed to notice this. A proper mailed patch to the list, or a quick mail to me would have been more obvious ;-) I went back to the the original mail and
Yes fair enough. I can just see the mail telling me to post them on linaro-kernel though.
scrolled down to the bottom to find the attachments in my steampunk email client, and I'll add that to my CCI topic branch.
Thanks.
The PMU support is a Frankenstein creation cobbled together from previous patches and intended to keep CCI support in Gator working. There are newer patches on the upstream lists which may break things again, but I've sorta stopped pro-actively trying to keep my branches up-to-date with latest work, as I don't seem to have the time any more and it seems a forlorn task. Especially as a lot of it seems under constant churn as people ague about how things should look. Best to just wait for it to turn up in mainline and deal with it them.
That may not be a bad approach. There were those patches a while back that killed various things like perf that crept in llct, it's a sign that unless there's some pedigree or direct support behind where the series came from it might be better to be without them.
-Andy
-- Tixy
On Tue, Aug 06, 2013 at 09:12:44PM +0800, Andy Green wrote:
On 6 August 2013 20:47, Mark Brown broonie@kernel.org wrote:
Please submit things normally - attachments are non-standard and difficult to work with (both from the point of view of applying and from the point of view of workflow) and if you don't mention them they're not always terribly visible either. I didn't actually notice there was anything here first time around...
I wonder why Google has an attachment button.
Attachments are obviously useful but as you should be aware given your kernel experience they're not part of the normal kernel development workflow - patches in the body of the e-mail (or git) are the normal way of handling things for projects that don't use a tool like gerrit, all the tooling and so on is based around that. There's good, solid reasoning behind the way the workflow is set up.
Like I say if you're going to do something unusual you should at least mention it but it's best avoided unless it's solving a problem.
- warning-elimination: ata: ata_hpa_resize default assignment
Issue is upstream but I can't reproduce original compiler warning
If the compiler figures it out we can probably drop this then. If it is still needed then it should be being submitted upstream.
Yes it's strange though I did not have a stroke and start editing code randomly, this was generating an error in the recent past.
Most likely someone fixed the warning some other way since you wrote the patch.
Hm you know the dynamic of people submitting things for your critique is not the only conversational mode that's possible, has that crossed your mind?
Sorry about that.
It would be really helpful if you could pay attention to the workflow stuff; I think a bunch of what you're seeing here is me getting grumpy due to the difficulty in working with the mail.
On 08/05/2013 03:37 PM, Andy Green wrote:
On 5 August 2013 18:59, Mark Brown broonie@kernel.org wrote:
On Mon, Aug 05, 2013 at 06:42:33PM +0800, Andy Green wrote:
On 5 August 2013 18:16, Mark Brown broonie@linaro.org wrote:
There may be other stuff lurking in linux-linaro that I'm not aware of, everything is supposed to be individually selected for backport.
Literally linux-linaro I'm not sure is useful for anything, the tree LTs are basing on is linux-linaro-core-tracking.
It's composed by rebase and then merges, so it's easy to see what's in there from a quick git log.
That doesn't help with understanding why any of it is there or what it's for.
Andrey is here hopefully he can do a Tixy-style breakdown.
Current linux-linaro-core-tracking topics: ========================================== (see the manifest for remote URLs)
configs/config-core-tracking generic (board independent) config fragments
configs/config-boards-tracking config fragments for the boards
android_jstultz/linaro-android-3.11-experimental-merge AOSP tree rebased to a recent -rc, may also contain Linaro patches being upstreamed
lt_arm/tracking-armlt-gator gator driver (originally from DS-5) provided by ARM LT
lt_arm/tracking-armlt-multi_pmu_v2 This is the big.LITTLE PMU support that was in the MP branch. (the MP branch has been dropped from llct)
lt_arm/tracking-armlt-iks is a rebase of Nicolas's iks branch: git://git.linaro.org/people/nico/linux.git iks with the big.LITTLE MP config fragment added.
lt_arm/tracking-armlt-iks-cpufreq is the cpufreq bits for IKS.
ynk/fixup_iks_linaro-android-3.11 is a fixup which doesn't show up as a conflict when lt_arm/tracking-armlt-iks and Android are merged because both topics increase NR_IPI to 7.
b_L_mp/ll-interactive-gov-updates The patches to the Android interactive governor. These changes are important for ARM big LITTLE platforms which want multiple instances of a governor to be available for a multi package system. Have been sent for inclusion into AOSP.
ynk/binder-3.8-rebase Just these 2 patches: "Android: Add support for 32-bit Binder calls in a 64-bit kernel" "binder: fix printk() format specifier to match userptr32_t type"
# Basic boards enablement: lt_samsung/llct/arndale-core-support basic Arndale support lt_broadcom/llct/capri-support basic support for Capri board
# Packaging: ynk/linaro-builddeb-tweaks a few patches to support kernel cross build with deb-pkg and to put the dtb files into the kernel image deb package according to linaro-hwpack-* tools expectations.
# Misc fixes which don't belong to any particular topic: ynk/llct-v3.10-misc-fixes "Add cross-build support to tools/lib/lk library" "perf tools: make perf to build in 3.9 kernel tree again" "ARM: crypto: sha1-armv4-large.S: fix SP handling" "KBuild: Allow scripts/* to be cross compiled"
Current linux-linaro topics: ============================
lt_arm/integration-linaro-vexpress ARM LT's integration branch to support Versatile Express
ynk/samsung-lt-tracking Samsung LT's integration branch with full Arndale support (the copy of Samsung LT's tag samsung-lt-v3.11-rc3)
configs/config-core-tracking and configs/config-boards-tracking - the same llct topics
Thanks, Andrey
Sounds reasonable.... attached is our current patch for your consideration. There's a permanent #warning about an unwind tables TODO this also knocks out the others are actual problems.
Please split this up into proper patches, and of course you should be submitting any fixes upstream if they're still present - if you're doing this sort of warning cleanup work it's going to be useful upstream too. I had a quick glance through and:
These are only applied on lsk and llct, I don't actually know where the code patched came from but I think they're all mainline. I'll check it out later.
- Things like just assigning a value to variables at declaration are worrying since that just shuts up the flow analysis warnings even if they're actually pointing out a genuine missed code path.
In this case it's okay, that var is written via a pointer arg to another call, but the call either returns an err or fills it in. The value is only used on non-error path. It's just keeping the compiler happy.
- The regmap change isn't something that I've seen upstream...
If you mean where did the original come from
commit 5a08d15602987bbdff3407d7645f95b7a70f1a6f Author: Stephen Warren swarren@nvidia.com Date: Wed Mar 20 17:02:02 2013 -0600
regmap: don't corrupt work buffer in _regmap_raw_write()
- For printf() warnings consider changing the printf() format specifier to be accurate rather than casting.
Yes fair enough.
-Andy
On Mon, Aug 05, 2013 at 11:23:19PM +0400, Andrey Konovalov wrote:
# Misc fixes which don't belong to any particular topic: ynk/llct-v3.10-misc-fixes "Add cross-build support to tools/lib/lk library" "perf tools: make perf to build in 3.9 kernel tree again" "ARM: crypto: sha1-armv4-large.S: fix SP handling"
These appear to be upstream anyway in one form or another.
"KBuild: Allow scripts/* to be cross compiled"
What's the upstreaming status on this?
On 08/05/2013 11:34 PM, Mark Brown wrote:
On Mon, Aug 05, 2013 at 11:23:19PM +0400, Andrey Konovalov wrote:
# Misc fixes which don't belong to any particular topic: ynk/llct-v3.10-misc-fixes "Add cross-build support to tools/lib/lk library"
The 2nd chunk is still not in the mainline. I'll check with Wookey.
"perf tools: make perf to build in 3.9 kernel tree again" "ARM: crypto: sha1-armv4-large.S: fix SP handling"
Right, v3.11 has the same changes in. Dropped these 2 commits from ynk/llct-v3.11-misc-fixes
These appear to be upstream anyway in one form or another.
"KBuild: Allow scripts/* to be cross compiled"
What's the upstreaming status on this?
Good question. There are no plans on upstreaming it atm
Thanks, Andrey
On Thu, Aug 08, 2013 at 05:20:46PM +0400, Andrey Konovalov wrote:
On 08/05/2013 11:34 PM, Mark Brown wrote:
These appear to be upstream anyway in one form or another.
"KBuild: Allow scripts/* to be cross compiled"
What's the upstreaming status on this?
Good question. There are no plans on upstreaming it atm
Any great reason why not? It doesn't seem particularly controversial or anything and definitely seems useful.
On 08/08/2013 05:30 PM, Mark Brown wrote:
On Thu, Aug 08, 2013 at 05:20:46PM +0400, Andrey Konovalov wrote:
On 08/05/2013 11:34 PM, Mark Brown wrote:
These appear to be upstream anyway in one form or another.
"KBuild: Allow scripts/* to be cross compiled"
What's the upstreaming status on this?
Good question. There are no plans on upstreaming it atm
Any great reason why not? It doesn't seem particularly controversial or anything and definitely seems useful.
Just the patch author is not with Linaro any more. So I am not very clear who would submit the patch.
On Thu, Aug 08, 2013 at 05:50:57PM +0400, Andrey Konovalov wrote:
On 08/08/2013 05:30 PM, Mark Brown wrote:
Any great reason why not? It doesn't seem particularly controversial or anything and definitely seems useful.
Just the patch author is not with Linaro any more. So I am not very clear who would submit the patch.
Hrm, OK. I'll try to take a look myself - from a brief Google it looks like nobody tried at all which is a shame. We should really be pushing people to upstream things so stuff like this doesn't happen.
On 08/08/2013 06:04 PM, Mark Brown wrote:
On Thu, Aug 08, 2013 at 05:50:57PM +0400, Andrey Konovalov wrote:
On 08/08/2013 05:30 PM, Mark Brown wrote:
Any great reason why not? It doesn't seem particularly controversial or anything and definitely seems useful.
Just the patch author is not with Linaro any more. So I am not very clear who would submit the patch.
Hrm, OK. I'll try to take a look myself
Thanks!
- from a brief Google it looks
like nobody tried at all which is a shame. We should really be pushing people to upstream things so stuff like this doesn't happen.
Yes, the things would be much easier if the patch were sent upstream soon after it had been created and we started using it.
-
Andrey Konovalov -
Andy Green -
John Stultz -
Jon Medhurst (Tixy) -
Mark Brown -
Mark Brown -
Riku Voipio