Messages in this thread | | | Date | Sat, 02 Jun 2012 23:01:05 -0400 | From | Len Brown <> | Subject | Re: [GIT PULL] ACPI & Power Management Patches for Linux-3.5-merge |
| |
On 06/02/2012 07:51 PM, Linus Torvalds wrote:
> On Fri, Jun 1, 2012 at 11:32 PM, Len Brown <lenb@kernel.org> wrote: >> >> ps. Sorry for sending this request at the tails of the merge window -- >> I'll try to be earlier next time. > > Christ, not only is it after I really wanted to do -rc1 (held up by > the tty locking problems), but it doesn't even compile. > > Find the bug (the compiler certainly did): > > static inline int acpi_pm_device_sleep_state(struct device *d, int *p, int m) > { > if (p) > *p = ACPI_STATE_D0; > return (m >= ACPI_STATE_D0 && <= ACPI_STATE_D3) ? m : ACPI_STATE_D0; > } > > and no, it wasn't a merge error. That's what it looks like in your tree.
>
> The commit was done yesterday. It clearly had *zero* testing.
Hmm.
This hunk is in the CONFIG_PM=n case.
Of the several hundred x86_64 and i386 kernels I build before sending you a pull request, only two do not have CONFIG_PM=y -- x86_64 allnoconfig and i386 allnoconfig. Like the other kernels, those build fine.
I'm curious what config and compiler tripped on this for you.
> Looking more at the pull as a result of this, I notice that almost > every commit in that tree is from yesterday, and thus cleary cannot > have been in -next.
Yes, I did check in Ying's patch this week, and a few others.
But a bunch of the patches have been in linux-next for some time.
I know you'd prefer patches to live in the tree frozen at the date that they were 1st checked in, but that doesn't work well when patches change. To update a patch in a series I need to re-base. Yes, I could re-base in place -- in the context of an rc that nobody anywhere (including me) will ever build or boot. Or I could re-base up to the latest release boundary which a lot of people (including me) will test. In this case I think I re-based everything up to 3.4.
> I was going to just fix up the obvious one-liner
> fixup, but looking at the bigger picture I'm going to say "3.6 > material" for this whole thing.
It would be sad for a simple, though embarrassing, issue with this patch to delay the other patches.
-Len
| |