On Fri, Mar 25, 2011 at 12:21:20PM +0100, Corentin Chary wrote:
> Ccing Dmitry and Matthew, they may want to comment that one.
>
> On Thu, Mar 24, 2011 at 11:02 PM, Andy Ross <andy.ross@xxxxxxxxxxxxx> wrote:
> > +static int asus_platform_probe(struct platform_device *pd)
> > +{
> > + struct asus_laptop *asus = dev_get_drvdata(&pd->dev);
> > +
> > + /* This is instantiated during platform driver initialization
> > + * becuase if it's done from underneath asus_acpi_add(), the
> > + * resulting input device can be grabbed by an early userspace
> > + * reader before ACPI initialization is finished and something
> > + * oopses underneath the acpi_evaluate_integer() call out of
> > + * pega_accel_poll(). Firmware bug? */
> > + pega_accel_probe(asus);
> > +
> > + return 0;
> > +}
>
> When is asus_platform_probe called exactly ? Because I'd say it's
> called during asus_platform_probe(), and that doesn't fix your issue
> right ?
This I do not quite understand... Do we bind acpi drivers to devices
before ACPI initialization is done? Then this should be fixed in ACPI
layer, but I doubt even early userspace is active at the time ACPI core
is being initialized. Also, input polling is done in a separate thread
so you not moving the poll out of ACPI binding thread but delay poll
execution by a few microseconds...
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
