27 Nov, 2008

1 commit

  • Now I know why I had strange "scheduling in atomic" problems:
    acpi_evaluate_integer() does malloc(..., irqs_disabled() ? GFP_ATOMIC
    : GFP_KERNEL)... which is (of course) broken.

    There's no way to reliably tell if we need GFP_ATOMIC or not from
    code, this one for example fails to detect spinlocks held.

    Fortunately, allocation seems small enough to be done on stack.

    Signed-off-by: Pavel Machek
    Acked-by: Bob Moore
    Signed-off-by: Len Brown

    Pavel Machek
     

11 Oct, 2008

1 commit

  • As of version 2.0, ACPI can return 64-bit integers. The current
    acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms.
    Change the argument to take a pointer to an acpi_integer so we support
    64-bit integers on all platforms.

    lenb: replaced use of "acpi_integer" with "unsigned long long"
    lenb: fixed bug in acpi_thermal_trips_update()

    Signed-off-by: Matthew Wilcox
    Signed-off-by: Len Brown

    Matthew Wilcox
     

23 Apr, 2008

1 commit

  • All Reference Objects returned via the AcpiEvaluteObject interface
    are now marked as type "REFERENCE" instead of "ANY". The type ANY
    is now reservered for NULL objects - either NULL package elements
    or unresolved named references.

    Signed-off-by: Bob Moore
    Signed-off-by: Alexey Starikovskiy
    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Bob Moore
     

12 Mar, 2008

1 commit


16 Feb, 2008

1 commit

  • replace acpi_util_eval_error macro with static function.

    Avoid these sparse warnings due to using buffer within the macro.
    drivers/acpi/utils.c:273:3: warning: symbol 'buffer' shadows an earlier one
    drivers/acpi/utils.c:259:21: originally declared here
    drivers/acpi/utils.c:279:3: warning: symbol 'buffer' shadows an earlier one
    drivers/acpi/utils.c:259:21: originally declared here
    drivers/acpi/utils.c:368:3: warning: symbol 'buffer' shadows an earlier one
    drivers/acpi/utils.c:348:21: originally declared here
    drivers/acpi/utils.c:375:3: warning: symbol 'buffer' shadows an earlier one
    drivers/acpi/utils.c:348:21: originally declared here
    drivers/acpi/utils.c:382:3: warning: symbol 'buffer' shadows an earlier one
    drivers/acpi/utils.c:348:21: originally declared here
    drivers/acpi/utils.c:402:4: warning: symbol 'buffer' shadows an earlier one
    drivers/acpi/utils.c:348:21: originally declared here

    Signed-off-by: Harvey Harrison
    Signed-off-by: Len Brown

    Harvey Harrison
     

13 Feb, 2007

1 commit


21 Dec, 2006

1 commit


14 Oct, 2006

1 commit


17 Aug, 2006

1 commit

  • __might_sleep+0x8e/0x93
    acpi_os_wait_semaphore+0x50/0xa3
    acpi_ut_acquire_mutex+0x28/0x6a
    acpi_ns_get_node+0x46/0x88
    acpi_ns_evaluate+0x2d/0xfc
    acpi_rs_set_srs_method_data+0xc5/0xe1
    acpi_set_current_resources+0x31/0x3f
    acpi_pci_link_set+0xfc/0x1a5
    irqrouter_resume+0x48/0x5f

    and

    __might_sleep+0x8e/0x93
    kmem_cache_alloc+0x2a/0x8f
    acpi_evaluate_integer+0x32/0x96
    acpi_bus_get_status+0x30/0x84
    acpi_pci_link_set+0x12a/0x1a5
    irqrouter_resume+0x48/0x5f

    http://bugzilla.kernel.org/show_bug.cgi?id=6810

    Signed-off-by: Len Brown

    Len Brown
     

30 Jun, 2006

1 commit


27 Jun, 2006

4 commits


14 May, 2006

1 commit


05 Aug, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds