Hi Ian, et. al.,
On 23-03-19 04:39, Ian W MORRISON wrote:
Hi Hans,
IMHO we need to root-cause this problem a bit more before applying this
kludge.
Can you provide an ACPI dump of one of the affected machines ?
Attached is an ACPI dump.
First of all sorry for taking way too long to get back to you on this.
So I've taken a look at all the _AEI code in the DSDT, a whole bunch of
it seems copy and pasted from various tablets, but nothing really
stands out as being a likely cause of this.
As such I guess we may need to go with the blacklist patch you suggested
which sucks, but having these devices not boot sucks even harder.
I guess this problem did not magically fix it self in the mean time
(with newer kernels) ?
Can you resubmit your patch with Andy's review remarks addressed?
In case you've lost Andy's reply I will reproduce the review remarks
below.
Regards,
Hans
p.s.
Andy's review remarks as promised:
> #include <linux/interrupt.h>
> #include <linux/mutex.h>
> #include <linux/pinctrl/pinctrl.h>
> +#include <linux/dmi.h>
This should be in order.
> /* Run deferred acpi_gpiochip_request_irqs() */
> +/* but exclude devices known to fail */
/*
* This should be done in the similar style
* as for multi-line comments. Like this one.
*/
> + dmi_id = dmi_first_match(skip_deferred_request_irqs_table);
> +
Redundant blank line.
> + if (! dmi_id) {
No space here, however, better to write positive conditional.
