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.