next-200110804 ARM build break (cpuidle_call_idle)

next-200110804 ARM build break (cpuidle_call_idle)

[Stephen Warren]

With next-20110804, I'm seeing the following on ARM:

arch/arm/kernel/process.c: In function 'cpu_idle':
arch/arm/kernel/process.c:200: error: implicit declaration of function 'cpuidle_call_idle'

This was previously fixed with:

https://lkml.org/lkml/2011/4/4/109

Commit 5f8cf82 (cpuidle: stop using pm_idle) converted arches to use
cpuidle_idle_call() but contained typos on ARM and SH transposing the
function name into cpuidle_call_idle().

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

(which I think was included directly in linux-next according to that
email thread)

However, commit 5f8cf82 isn't in linux-next any more, but instead,
a0bfa13 "cpuidle: stop depending on pm_idle" has replaced it, and has
the same issue.

Applying Mark's previous fix solves the build problem.

Related, I see that linux-next merges
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git idle-test
yet that branch doesn't seem to exist anymore.

-- 
nvpublic

Re: next-200110804 ARM build break (cpuidle_call_idle)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

Hi Stephen,

[Just quickly responding to one part of your email]

On Thu, 4 Aug 2011 13:35:59 -0700 Stephen Warren <swarren@nvidia.com> wrote:
>
> Related, I see that linux-next merges
> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git idle-test
> yet that branch doesn't seem to exist anymore.

I actually get that branch from linux-idle-2.6.git - I had a typo in my
documentation, but was still fetching the correct tree.  Sorry about the
confusion.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: next-200110804 ARM build break (cpuidle_call_idle)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

Hi Stephen,

On Thu, 4 Aug 2011 13:35:59 -0700 Stephen Warren <swarren@nvidia.com> wrote:
>
> With next-20110804, I'm seeing the following on ARM:
> 
> arch/arm/kernel/process.c: In function 'cpu_idle':
> arch/arm/kernel/process.c:200: error: implicit declaration of function 'cpuidle_call_idle'
> 
> This was previously fixed with:
> 
> https://lkml.org/lkml/2011/4/4/109
> 
> Commit 5f8cf82 (cpuidle: stop using pm_idle) converted arches to use
> cpuidle_idle_call() but contained typos on ARM and SH transposing the
> function name into cpuidle_call_idle().
> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> 
> (which I think was included directly in linux-next according to that
> email thread)

Yeah, briefly by the looks of things.

> However, commit 5f8cf82 isn't in linux-next any more, but instead,
> a0bfa13 "cpuidle: stop depending on pm_idle" has replaced it, and has
> the same issue.

It was included first on April 4 and removed after I apllied tha bove fix
on April 15.  From April 18 on, it was not in the tree at all.  I don't
know why it has come back :-(

> Applying Mark's previous fix solves the build problem.

Hi Len.  This patch was wrong the first time around ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: next-200110804 ARM build break (cpuidle_call_idle)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]

Hi Linus,

On Fri, 5 Aug 2011 09:29:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 4 Aug 2011 13:35:59 -0700 Stephen Warren <swarren@nvidia.com> wrote:
> >
> > With next-20110804, I'm seeing the following on ARM:
> > 
> > arch/arm/kernel/process.c: In function 'cpu_idle':
> > arch/arm/kernel/process.c:200: error: implicit declaration of function 'cpuidle_call_idle'
> > 
> > This was previously fixed with:
> > 
> > https://lkml.org/lkml/2011/4/4/109
> > 
> > Commit 5f8cf82 (cpuidle: stop using pm_idle) converted arches to use
> > cpuidle_idle_call() but contained typos on ARM and SH transposing the
> > function name into cpuidle_call_idle().
> > 
> > Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> > 
> > (which I think was included directly in linux-next according to that
> > email thread)
> 
> Yeah, briefly by the looks of things.
> 
> > However, commit 5f8cf82 isn't in linux-next any more, but instead,
> > a0bfa13 "cpuidle: stop depending on pm_idle" has replaced it, and has
> > the same issue.
> 
> It was included first on April 4 and removed after I apllied tha bove fix
> on April 15.  From April 18 on, it was not in the tree at all.  I don't
> know why it has come back :-(
> 
> > Applying Mark's previous fix solves the build problem.
> 
> Hi Len.  This patch was wrong the first time around ...

More fun!

The last three commits in the idle tree that you took from Len were in
linux-next until April 15 and then disappeared until yesterday.  The last
of these was broken back then and has been committed exactly the same now
and still breaks arm and sh.

I have reverted that commit from your tree for today ...
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: next-200110804 ARM build break (cpuidle_call_idle)

[Linus Torvalds]

On Thu, Aug 4, 2011 at 2:52 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> The last three commits in the idle tree that you took from Len were in
> linux-next until April 15 and then disappeared until yesterday.  The last
> of these was broken back then and has been committed exactly the same now
> and still breaks arm and sh.
>
> I have reverted that commit from your tree for today ...

Len, this is *exactly* why I com plained about the git trees you pushed to me.

And then I pulled anyway, because you and others convinced me things
had been in -next despite the commit dates being odd.

Let's just say that I'm really *really* disappointed. And dammit, you
need to fix your workflow. Don't add random commits late. If you're
offline, you're offline, and you send the old tested tree, not some
last-minute crap.

Next time I find reason to complain, I just won't pull.  In fact, I'm
seriously considering a rather draconian measure for next merge
window: I'll fetch the -next tree when I open the merge window, and if
I get anything but trivial fixes that don't show up in that "next tree
at the point of merge window open", I'll just ignore that pull
request. Because clearly people are just not being careful enough.

It's really *very* annoying to hear that a bug has been known about
for weeks (or months) and just not fixed, and then shows up again THE
SAME DAY that the pull request is sent to me.

                  Linus

Re: next-200110804 ARM build break (cpuidle_call_idle)

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> [...] In fact, I'm seriously considering a rather draconian measure 
> for next merge window: I'll fetch the -next tree when I open the 
> merge window, and if I get anything but trivial fixes that don't 
> show up in that "next tree at the point of merge window open", I'll 
> just ignore that pull request. Because clearly people are just not 
> being careful enough.

That would be really nice - in hindsight, had you done that in this 
cycle it would have solved about 80% of the merge window bugs i ran 
into!

I have trouble getting my own fixes out on time because -git is so 
untestable at the moment and i need to test on -git now that our new 
bits are upstream.

 [ In fact i'd even argue that the snapshot should be a couple of 
   days _before_ the merge window opening. The trivial annoyances and
   serious showstoppers need a couple of days of latency to get 
   discovered in linux-next and there's always a late rush of getting 
   stuff into linux-next just before the final release. linux-next
   also has weekend latency which can add up to 3 days to the 
   normally 2-3 days latency of discovering showstoppers. ]

People can still try to tempt you with late stuff, with an [RFC GIT 
PULL] tag, clearly and visibly declaring that it's a workflow 
exception and that it's fully discretional on your side with no 
maintenance problems if it's skipped to the next merge window.

Thanks,

	Ingo

RE: next-200110804 ARM build break (cpuidle_call_idle)

[Brown, Len]

> > The last three commits in the idle tree that you took from Len were in
> > linux-next until April 15 and then disappeared until yesterday.  The last
> > of these was broken back then and has been committed exactly the same now
> > and still breaks arm and sh.
> >
> > I have reverted that commit from your tree for today ...
> 
> Len, this is *exactly* why I com plained about the git trees you pushed to me.

Ugh, 3 flubs from me in 1 day -- I should have taken the day off!
I actually fixed that typo, but failed to include it:-(

> And then I pulled anyway, because you and others convinced me things
> had been in -next despite the commit dates being odd.
> 
> Let's just say that I'm really *really* disappointed. And dammit, you
> need to fix your workflow. Don't add random commits late. If you're
> offline, you're offline, and you send the old tested tree, not some
> last-minute crap.

Okay.

> Next time I find reason to complain, I just won't pull.  In fact, I'm
> seriously considering a rather draconian measure for next merge
> window: I'll fetch the -next tree when I open the merge window, and if
> I get anything but trivial fixes that don't show up in that "next tree
> at the point of merge window open", I'll just ignore that pull
> request. Because clearly people are just not being careful enough.

Agreed.  I don't think it would be 'Draconian' to enforce
a pre-merge-window-merge-window.  Indeed, if it were automated
and the timing were clearly known ahead of time, then
the structure would be helplful.

thanks,
-Len