Eric Lee / smarc-fsl-linux-kernel

06 Dec, 2006

1 commit

05 Dec, 2006

1 commit

04 Dec, 2006

1 commit

02 Dec, 2006

1 commit

  • 465ae641e   ACPI: Change ACPI to use dev_archdata instead of firmware_data ... Browse Code »

    Change ACPI to use dev_archdata instead of firmware_data

    This patch changes ACPI to use the new dev_archdata on i386, x86_64
    and ia64 (is there any other arch using ACPI ?) to store it's
    acpi_handle.

    It also removes the firmware_data field from struct device as this
    was the only user.

    Only build-tested on x86

    Signed-off-by: Benjamin Herrenschmidt
    Cc: Len Brown
    Signed-off-by: Greg Kroah-Hartman

    Benjamin Herrenschmidt
     

24 Nov, 2006

1 commit

  • 0916bd3eb   [PATCH] Correct bound checking from the value returned from _PPC method. ... Browse Code »

    processor_perflib.c::acpi_processor_ppc_notifier() check if the value
    returned by the processor's _PPC method is 0 and return failed if so.
    This is wrong since 0 indicate that the bios think the processor can go
    to the highest frequency. This patch for example fix the HP NX 6125 to
    allow its highest frequency to be available.

    Signed-off-by: Bruno Ducrot
    Cc: "Pallipadi, Venkatesh"
    Signed-off-by: Dave Jones
    Signed-off-by: Linus Torvalds

    Dave Jones
     

22 Nov, 2006

1 commit

  • 65f27f384   WorkStruct: Pass the work_struct pointer instead of context data ... Browse Code »

    Pass the work_struct pointer to the work function rather than context data.
    The work function can use container_of() to work out the data.

    For the cases where the container of the work_struct may go away the moment the
    pending bit is cleared, it is made possible to defer the release of the
    structure by deferring the clearing of the pending bit.

    To make this work, an extra flag is introduced into the management side of the
    work_struct. This governs auto-release of the structure upon execution.

    Ordinarily, the work queue executor would release the work_struct for further
    scheduling or deallocation by clearing the pending bit prior to jumping to the
    work function. This means that, unless the driver makes some guarantee itself
    that the work_struct won't go away, the work function may not access anything
    else in the work_struct or its container lest they be deallocated.. This is a
    problem if the auxiliary data is taken away (as done by the last patch).

    However, if the pending bit is *not* cleared before jumping to the work
    function, then the work function *may* access the work_struct and its container
    with no problems. But then the work function must itself release the
    work_struct by calling work_release().

    In most cases, automatic release is fine, so this is the default. Special
    initiators exist for the non-auto-release case (ending in _NAR).

    Signed-Off-By: David Howells

    David Howells
     

18 Nov, 2006

1 commit

  • b976fe19a   Revert "ACPI: created a dedicated workqueue for notify() execution" ... Browse Code »

    This reverts commit 37605a6900f6b4d886d995751fcfeef88c4e462c.

    Again.

    This same bug has now been introduced twice: it was done earlier by
    commit b8d35192c55fb055792ff0641408eaaec7c88988, only to be reverted
    last time in commit 72945b2b90a5554975b8f72673ab7139d232a121.

    We must NOT try to queue up notify handlers to another thread than the
    normal ACPI execution thread, because the notifications on some systems
    seem to just keep on accumulating until we run out of memory and/or
    threads.

    Keeping events within the one deferred execution thread automatically
    throttles the events properly.

    At least the Compaq N620c will lock up completely on the first thermal
    event without this patch reverted.

    Cc: David Brownell
    Cc: Len Brown
    Cc: Alexey Starikovskiy
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

21 Oct, 2006

3 commits

  • 887b95931   [PATCH] acpi memory hotplug: remove strange add_memory fail message ... Browse Code »

    I wrote a patch to avoid redundant memory hot-add call at boot time. This
    was cause of strange fail message of memory hotplug like "ACPI: add_memory
    failed". Memory is recognized by early boot code with EFI/E820.

    But, if DSDT describes memory devices for them, then hot-add code is called
    for already recognized memory, and it shows fail messages with -EEXIST.
    So, sys admin will misunderstand this message as something wrong by it.

    This patch avoids them by preventing redundant hot-add call until
    completion of driver initialization.

    [akpm@osdl.org: cleanups]
    Signed-off-by: Yasunori Goto
    Cc: "Brown, Len"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Yasunori Goto
     
  • 6cbe44cd8   [PATCH] Change log level of a message of acpi_memhotplug to KERN_DEBUG ... Browse Code »

    I suppose this message seems quite useless except debugging. It just shows
    "Hotplug Mem Device". System admin can't know anything by this message.
    So, I would like to change it to KERN_DEBUG.

    Signed-off-by: Yasunori Goto
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Yasunori Goto
     
  • c5a114f1f   [PATCH] fix "ACPI: Processor native C-states using MWAIT" ... Browse Code »

    This patch breaks C-state discovery on my IBM IntelliStation Z30 because
    the return value of acpi_processor_get_power_info_fadt is not assigned to
    "result" in the case that acpi_processor_get_power_info_cst returns
    -ENODEV. Thus, if ACPI provides C-state data via the FADT and not _CST (as
    is the case on this machine), we incorrectly exit the function with -ENODEV
    after reading the FADT. The attached patch sets the value of result so
    that we don't exit early.

    Signed-off-by: Darrick J. Wong
    Acked-by: "Pallipadi, Venkatesh"
    Acked-by: "Brown, Len"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Darrick J. Wong
     

17 Oct, 2006

1 commit

14 Oct, 2006

29 commits