On Tuesday, July 09, 2013 12:37:26 PM Mika Westerberg wrote:
> On Tue, Jul 09, 2013 at 02:20:31AM +0200, Rafael J. Wysocki wrote:
> > @@ -953,37 +937,49 @@ static void acpiphp_sanitize_bus(struct
> > * ACPI event handlers
> > */
> >
> > -static acpi_status
> > -check_sub_bridges(acpi_handle handle, u32 lvl, void *context, void **rv)
> > +static acpi_status check_sub_bridges(acpi_handle handle, u32 lvl, void
> > *data,
> > + void **rv)
> > {
> > - struct acpiphp_bridge *bridge;
> > - char objname[64];
> > - struct acpi_buffer buffer = { .length = sizeof(objname),
> > - .pointer = objname };
> > + struct acpiphp_context *context = acpiphp_get_context(handle);
> > +
> > + if (!context)
> > + return AE_OK;
> >
> > - bridge = acpiphp_handle_to_bridge(handle);
> > - if (bridge) {
> > + if (context->bridge) {
> > + struct acpiphp_bridge *bridge = context->bridge;
> > + char objname[64];
> > + struct acpi_buffer buffer = { .length = sizeof(objname),
> > + .pointer = objname };
> > +
> > + get_bridge(bridge);
> > acpi_get_name(handle, ACPI_FULL_PATHNAME, &buffer);
> > - dbg("%s: re-enumerating slots under %s\n",
> > - __func__, objname);
> > + dbg("%s: re-enumerating slots under %s\n", __func__, objname);
>
> Although not related to this patch directly, how about using
> acpi_handle_debug() or similar here?
Well, we don't have acpi_handle_debug() and I remember there was a reason why,
but I can't recall what the reason was at the moment. :-)
> > acpiphp_check_bridge(bridge);
> > put_bridge(bridge);
> > }
> > + acpiphp_put_context(context);
> > return AE_OK ;
> > }
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
