| Message ID | 20240903014317.38858-1-tamim@fusetak.com |
|---|---|
| State | Accepted |
| Commit | 49e9cc315604972cc14868cb67831e3e8c3f1470 |
| Headers | show |
| Series | ACPI: resource: Skip IRQ override on Asus Vivobook Go E1404GAB | expand |
On 03.09.24 03:43, Tamim Khan wrote: > Like other Asus Vivobooks, the Asus Vivobook Go E1404GAB has a DSDT > that describes IRQ 1 as ActiveLow, while the kernel overrides to Edge_High. > This override prevents the internal keyboard from working. This patch fixes > this problem by adding this laptop to the table that prevents the kernel from > overriding the IRQ. > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=219212 Thx for that. FWIW, I by chance noticed another such report about the E1404GA: https://bugzilla.kernel.org/show_bug.cgi?id=219224 Ciao, Thorsten
On 05.09.24 11:51, Thorsten Leemhuis wrote: > On 03.09.24 03:43, Tamim Khan wrote: >> Like other Asus Vivobooks, the Asus Vivobook Go E1404GAB has a DSDT >> that describes IRQ 1 as ActiveLow, while the kernel overrides to Edge_High. >> This override prevents the internal keyboard from working. This patch fixes >> this problem by adding this laptop to the table that prevents the kernel from >> overriding the IRQ. >> >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=219212 > > Thx for that. FWIW, I by chance noticed another such report about the > E1404GA: https://bugzilla.kernel.org/show_bug.cgi?id=219224 TWIMC, shortly after sending this mail I noticed there is another request for a quirk that was send to the list, bug afaics fall through the cracks. See here: https://lore.kernel.org/all/1226760b-4699-4529-bf57-6423938157a3@wanadoo.fr/ It afaics add a X1704VAP: { /* Asus Vivobook X1704V */ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), DMI_MATCH(DMI_BOARD_NAME, "X1704VAP"), }, }, Ciao, Thorsten
[CCing Hans] On 05.09.24 12:45, Thorsten Leemhuis wrote: > On 05.09.24 11:51, Thorsten Leemhuis wrote: >> On 03.09.24 03:43, Tamim Khan wrote: >>> Like other Asus Vivobooks, the Asus Vivobook Go E1404GAB has a DSDT >>> that describes IRQ 1 as ActiveLow, while the kernel overrides to Edge_High. >>> This override prevents the internal keyboard from working. This patch fixes >>> this problem by adding this laptop to the table that prevents the kernel from >>> overriding the IRQ. >>> >>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=219212 >> >> Thx for that. FWIW, I by chance noticed another such report about the >> E1404GA: https://bugzilla.kernel.org/show_bug.cgi?id=219224 > > TWIMC, shortly after sending this mail I noticed there is another request > for a quirk that was send to the list, bug afaics fall through the > cracks. See here: > https://lore.kernel.org/all/1226760b-4699-4529-bf57-6423938157a3@wanadoo.fr/ > > It afaics add a X1704VAP: > > { > /* Asus Vivobook X1704V */ > .matches = { > DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), > DMI_MATCH(DMI_BOARD_NAME, "X1704VAP"), > }, > }, FWIW, noticed another such report, this time about the B2502CVA: https://bugzilla.kernel.org/show_bug.cgi?id=217760#c12 """ > adding this section to file drivers/acpi/resource.c helped; if someone could do an official patch it would be great :-| > > { > /* Asus ExpertBook B2502CVA */ > .matches = { > DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), > DMI_MATCH(DMI_BOARD_NAME, "B2502CVA"), > }, """ This is not a regression, but given how frequently I notice these issues please as a bystander allow me to ask: is there maybe some way to improve the situation so that we do not have to add all these and likely many other Asus Laptops to that file? Ciao, Thorsten
Hi Thorsten, On 25-Sep-24 1:56 PM, Thorsten Leemhuis wrote: > [CCing Hans] Can you next time maybe also add a bit of text explaining why ? Often the why is trivial, but in this case I wonder what input you want from me, see below. > On 05.09.24 12:45, Thorsten Leemhuis wrote: >> On 05.09.24 11:51, Thorsten Leemhuis wrote: >>> On 03.09.24 03:43, Tamim Khan wrote: >>>> Like other Asus Vivobooks, the Asus Vivobook Go E1404GAB has a DSDT >>>> that describes IRQ 1 as ActiveLow, while the kernel overrides to Edge_High. >>>> This override prevents the internal keyboard from working. This patch fixes >>>> this problem by adding this laptop to the table that prevents the kernel from >>>> overriding the IRQ. >>>> >>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=219212 >>> >>> Thx for that. FWIW, I by chance noticed another such report about the >>> E1404GA: https://bugzilla.kernel.org/show_bug.cgi?id=219224 >> >> TWIMC, shortly after sending this mail I noticed there is another request >> for a quirk that was send to the list, bug afaics fall through the >> cracks. See here: >> https://lore.kernel.org/all/1226760b-4699-4529-bf57-6423938157a3@wanadoo.fr/ >> >> It afaics add a X1704VAP: >> >> { >> /* Asus Vivobook X1704V */ >> .matches = { >> DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), >> DMI_MATCH(DMI_BOARD_NAME, "X1704VAP"), >> }, >> }, > > FWIW, noticed another such report, this time about the B2502CVA: > https://bugzilla.kernel.org/show_bug.cgi?id=217760#c12 Ok, I wonder did you Cc me so that I can write / submit patches upstream for these ones? It seems that there are 3 missing models: - E1404GA: https://bugzilla.kernel.org/show_bug.cgi?id=219224 - X1704VAP https://lore.kernel.org/all/1226760b-4699-4529-bf57-6423938157a3@wanadoo.fr/ - B2502CV: https://bugzilla.kernel.org/show_bug.cgi?id=217760#c12 Which someone needs to submit upstream, right ? > """ >> adding this section to file drivers/acpi/resource.c helped; if someone could do an official patch it would be great :-| >> >> { >> /* Asus ExpertBook B2502CVA */ >> .matches = { >> DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), >> DMI_MATCH(DMI_BOARD_NAME, "B2502CVA"), >> }, > """ > > This is not a regression, but given how frequently I notice these issues > please as a bystander allow me to ask: is there maybe some way to > improve the situation so that we do not have to add all these and likely > many other Asus Laptops to that file? This has been discussed before and unfortunately there is no other way to deal with this. There has been some discussion about reading back the polarity and edge/level from the hardware for the keyboard IRQ to get the values which the BIOS has setup. But it is uncertain if this will work and no one is working on this. Regards, Hans
On 25.09.24 16:31, Hans de Goede wrote: > > On 25-Sep-24 1:56 PM, Thorsten Leemhuis wrote: >> [CCing Hans] > Can you next time maybe also add a bit of text explaining why ? Sorry, yes, you are right, will keep that in mind. >> On 05.09.24 12:45, Thorsten Leemhuis wrote: >>> On 05.09.24 11:51, Thorsten Leemhuis wrote: >>>> On 03.09.24 03:43, Tamim Khan wrote: >>>>> Like other Asus Vivobooks, the Asus Vivobook Go E1404GAB has a DSDT >>>>> that describes IRQ 1 as ActiveLow, while the kernel overrides to Edge_High. >>>>> This override prevents the internal keyboard from working. This patch fixes >>>>> this problem by adding this laptop to the table that prevents the kernel from >>>>> overriding the IRQ. >>>>> >>>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=219212 >>>> Thx for that. FWIW, I by chance noticed another such report about the >>>> E1404GA: https://bugzilla.kernel.org/show_bug.cgi?id=219224 >>> >>> TWIMC, shortly after sending this mail I noticed there is another request >>> for a quirk that was send to the list, bug afaics fall through the >>> cracks. See here: >>> https://lore.kernel.org/all/1226760b-4699-4529-bf57-6423938157a3@wanadoo.fr/ >>> >>> It afaics add a X1704VAP: > [...] > > Ok, I wonder did you Cc me so that I can write / submit patches upstream > for these ones? Not really. Of course it would be nice if you or someone else took care of that one and... > It seems that there are 3 missing models: > - E1404GA: https://bugzilla.kernel.org/show_bug.cgi?id=219224 > - X1704VAP https://lore.kernel.org/all/1226760b-4699-4529-bf57-6423938157a3@wanadoo.fr/ > - B2502CV: https://bugzilla.kernel.org/show_bug.cgi?id=217760#c12 > > Which someone needs to submit upstream, right ? ...these as well -- and ideally would even be willing to act as go-to person from now on in case more of these quirk entries are needed, which I guess will be the case. But given the backstory (see below) I don't think you or anyone else is obliged to do this, even if the current situation is parlty caused by regressions and recent fixes for them. >> """ >>> adding this section to file drivers/acpi/resource.c helped; if someone could do an official patch it would be great :-| >>> >>> { >>> /* Asus ExpertBook B2502CVA */ >>> .matches = { >>> DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), >>> DMI_MATCH(DMI_BOARD_NAME, "B2502CVA"), >>> }, >> """ >> >> This is not a regression, but given how frequently I notice these issues >> please as a bystander allow me to ask: is there maybe some way to >> improve the situation so that we do not have to add all these and likely >> many other Asus Laptops to that file? > > This has been discussed before and unfortunately there is no other way > to deal with this. There has been some discussion about reading back > the polarity and edge/level from the hardware for the keyboard IRQ > to get the values which the BIOS has setup. But it is uncertain if this > will work and no one is working on this. A refresher like this was more what I was fishing for. Thx for this. Now that you wrote it, it makes me think: given the amount of quirk entries we apparently need I wonder if it might be wise to revisit this at some point in the not to distant future, as I suspect otherwise sooner or later Linus might yell at all of us with something along the lines of "the kernel is clearly broken, why did we work around this with lots of quirk entries instead of fixing this for real". Something like that happened in a somewhat (but not exactly) similar situation a year ago, and it iirc was not the first time. Writing this lead to another thought: does anyone have contacts to Asus and could just ask if there is some generic way to detect which of their Laptops need a quirk? Ciao, Thorsten
Hi Thorsten, On 26-Sep-24 12:18 PM, Thorsten Leemhuis wrote: > On 25.09.24 16:31, Hans de Goede wrote: >> >> On 25-Sep-24 1:56 PM, Thorsten Leemhuis wrote: >>> [CCing Hans] >> Can you next time maybe also add a bit of text explaining why ? > > Sorry, yes, you are right, will keep that in mind. > >>> On 05.09.24 12:45, Thorsten Leemhuis wrote: >>>> On 05.09.24 11:51, Thorsten Leemhuis wrote: >>>>> On 03.09.24 03:43, Tamim Khan wrote: >>>>>> Like other Asus Vivobooks, the Asus Vivobook Go E1404GAB has a DSDT >>>>>> that describes IRQ 1 as ActiveLow, while the kernel overrides to Edge_High. >>>>>> This override prevents the internal keyboard from working. This patch fixes >>>>>> this problem by adding this laptop to the table that prevents the kernel from >>>>>> overriding the IRQ. >>>>>> >>>>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=219212 >>>>> Thx for that. FWIW, I by chance noticed another such report about the >>>>> E1404GA: https://bugzilla.kernel.org/show_bug.cgi?id=219224 >>>> >>>> TWIMC, shortly after sending this mail I noticed there is another request >>>> for a quirk that was send to the list, bug afaics fall through the >>>> cracks. See here: >>>> https://lore.kernel.org/all/1226760b-4699-4529-bf57-6423938157a3@wanadoo.fr/ >>>> >>>> It afaics add a X1704VAP: >> [...] >> >> Ok, I wonder did you Cc me so that I can write / submit patches upstream >> for these ones? > > Not really. Of course it would be nice if you or someone else took care > of that one and... > >> It seems that there are 3 missing models: >> - E1404GA: https://bugzilla.kernel.org/show_bug.cgi?id=219224 >> - X1704VAP https://lore.kernel.org/all/1226760b-4699-4529-bf57-6423938157a3@wanadoo.fr/ >> - B2502CV: https://bugzilla.kernel.org/show_bug.cgi?id=217760#c12 >> >> Which someone needs to submit upstream, right ? > > ...these as well -- and ideally would even be willing to act as go-to > person from now on in case more of these quirk entries are needed, which > I guess will be the case. But given the backstory (see below) I don't > think you or anyone else is obliged to do this, even if the current > situation is parlty caused by regressions and recent fixes for them. I have already done a bunch of these patches. So I would be happy to submit more of these, but someone needs to bring them to my attention first. Also maybe Paul Menzel (added to the Cc) and Tamim Khan can help with adding more quirks, when reports come in ? Either way I have submitted a set of patches to add quirks for the 3 new known broken models now. >>> """ >>>> adding this section to file drivers/acpi/resource.c helped; if someone could do an official patch it would be great :-| >>>> >>>> { >>>> /* Asus ExpertBook B2502CVA */ >>>> .matches = { >>>> DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), >>>> DMI_MATCH(DMI_BOARD_NAME, "B2502CVA"), >>>> }, >>> """ >>> >>> This is not a regression, but given how frequently I notice these issues >>> please as a bystander allow me to ask: is there maybe some way to >>> improve the situation so that we do not have to add all these and likely >>> many other Asus Laptops to that file? >> >> This has been discussed before and unfortunately there is no other way >> to deal with this. There has been some discussion about reading back >> the polarity and edge/level from the hardware for the keyboard IRQ >> to get the values which the BIOS has setup. But it is uncertain if this >> will work and no one is working on this. > > A refresher like this was more what I was fishing for. Thx for this. > > Now that you wrote it, it makes me think: given the amount of quirk > entries we apparently need I wonder if it might be wise to revisit this > at some point in the not to distant future, as I suspect otherwise > sooner or later Linus might yell at all of us with something along the > lines of "the kernel is clearly broken, why did we work around this with > lots of quirk entries instead of fixing this for real". Something like > that happened in a somewhat (but not exactly) similar situation a year > ago, and it iirc was not the first time. I hear you, but I don't really know anyone who has both the expertise as well as the bandwidth to deal with this. > Writing this lead to another thought: does anyone have contacts to Asus > and could just ask if there is some generic way to detect which of their > Laptops need a quirk? I don't have any contacts at Asus. Regards, Hans
On 27.09.24 16:19, Hans de Goede wrote: > On 26-Sep-24 12:18 PM, Thorsten Leemhuis wrote: >> On 25.09.24 16:31, Hans de Goede wrote: >>> On 25-Sep-24 1:56 PM, Thorsten Leemhuis wrote: >>>>> https://lore.kernel.org/all/1226760b-4699-4529-bf57-6423938157a3@wanadoo.fr/ >>> Ok, I wonder did you Cc me so that I can write / submit patches upstream >>> for these ones? >> >> Not really. Of course it would be nice if you or someone else took care >> of that one and... >> >>> It seems that there are 3 missing models: >>> - E1404GA: https://bugzilla.kernel.org/show_bug.cgi?id=219224 >>> - X1704VAP https://lore.kernel.org/all/1226760b-4699-4529-bf57-6423938157a3@wanadoo.fr/ >>> - B2502CV: https://bugzilla.kernel.org/show_bug.cgi?id=217760#c12 >>> >>> Which someone needs to submit upstream, right ? >> >> ...these as well -- and ideally would even be willing to act as go-to >> person from now on in case more of these quirk entries are needed, which >> I guess will be the case. But given the backstory (see below) I don't >> think you or anyone else is obliged to do this, even if the current >> situation is parlty caused by regressions and recent fixes for them. > > I have already done a bunch of these patches. So I would be happy to > submit more of these, but someone needs to bring them to my attention first. Great, good to know. > Also maybe Paul Menzel (added to the Cc) and Tamim Khan can help with > adding more quirks, when reports come in ? That would be great, but nevertheless allow me to ask: Does anyone now if kernelnewbies has some place where we could submit requests for creating quirk entries? > Either way I have submitted a set of patches to add quirks for the 3 new > known broken models now. Many thx! >> Writing this lead to another thought: does anyone have contacts to Asus >> and could just ask if there is some generic way to detect which of their >> Laptops need a quirk? > I don't have any contacts at Asus. I asked in the fediverse, maybe someone knows somebody that can help. And if not: no harm done. Have a nice week everyone! Ciao, Thorsten
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index df5d5a554b38..c65c72c515e6 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -503,6 +503,13 @@ static const struct dmi_system_id irq1_level_low_skip_override[] = { DMI_MATCH(DMI_BOARD_NAME, "B2502FBA"), }, }, + { + /* Asus Vivobook Go E1404GAB */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), + DMI_MATCH(DMI_BOARD_NAME, "E1404GAB"), + }, + }, { /* Asus Vivobook E1504GA */ .matches = {
Like other Asus Vivobooks, the Asus Vivobook Go E1404GAB has a DSDT that describes IRQ 1 as ActiveLow, while the kernel overrides to Edge_High. This override prevents the internal keyboard from working. This patch fixes this problem by adding this laptop to the table that prevents the kernel from overriding the IRQ. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219212 Signed-off-by: Tamim Khan <tamim@fusetak.com> --- drivers/acpi/resource.c | 7 +++++++ 1 file changed, 7 insertions(+)