lkml.org 
[lkml]   [2012]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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


    \
     
     \ /
      Last update: 2012-06-03 05:41    [W:0.037 / U:32.584 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site