On 6 August 2013 20:47, Mark Brown <broo...@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. >> 4) 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. >> 6) 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. >> 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. > > 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. >> 8) 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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
