Hi, Thorsten here, the Linux kernel's regression tracker.
I noticed a regression report in bugzilla.kernel.org. As many (most?)
kernel developers don't keep an eye on it, I decided to forward it by mail.
Chuanhong Guo, apparently it's cause by a change of yours.
Note, you have to use bugzilla to reach the reporter, as I sadly[1] can
not CCed them in mails like this.
Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=217394 :
> Matthew 2023-05-03 02:28:33 UTC
>
> Reverting the changes found in this patch fixes the issue:
>> https://lore.kernel.org/all/[email protected]/
>
> With that patch the AT Translated Set 2 Keyboard doesn't show up with the evtest and is not usable.
>
> Hardware:
>
> Aya Neo Air Plus
> AMD Ryzen 7 6800U
See the ticket for more details.
BTW: there apparently is another IRQ override needed for a different
machine. See https://bugzilla.kernel.org/show_bug.cgi?id=216804#c8 for
details (ignore the comments before that, the quirk entry for that
machine was merged; comment 8 and all related to it really should have a
separate bug; that's also why this partly fall through the cracks here
:-/ ). The user is currently trying to create a patch.
[TLDR for the rest of this mail: I'm adding this report to the list of
tracked Linux kernel regressions; the text you find below is based on a
few templates paragraphs you might have encountered already in similar
form.]
BTW, let me use this mail to also add the report to the list of tracked
regressions to ensure it's doesn't fall through the cracks:
#regzbot introduced: 9946e39fe8d0
https://bugzilla.kernel.org/show_bug.cgi?id=217394
#regzbot title: acpi: IRQ override quirk needed for Aya Neo Air Plus 6800U
#regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.
Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (e.g. the buzgzilla ticket and maybe this mail as well, if
this thread sees some discussion). See page linked in footer for details.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
[1] because bugzilla.kernel.org tells users upon registration their
"email address will never be displayed to logged out users"
+linux-input
On 5/3/2023 7:58 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker.
>
> I noticed a regression report in bugzilla.kernel.org. As many (most?)
> kernel developers don't keep an eye on it, I decided to forward it by mail.
>
> Chuanhong Guo, apparently it's cause by a change of yours.
>
> Note, you have to use bugzilla to reach the reporter, as I sadly[1] can
> not CCed them in mails like this.
>
> Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=217394 :
>
>> Matthew 2023-05-03 02:28:33 UTC
>>
>> Reverting the changes found in this patch fixes the issue:
>>> https://lore.kernel.org/all/[email protected]/
>> With that patch the AT Translated Set 2 Keyboard doesn't show up with the evtest and is not usable.
>>
>> Hardware:
>>
>> Aya Neo Air Plus
>> AMD Ryzen 7 6800U
> See the ticket for more details.
>
> BTW: there apparently is another IRQ override needed for a different
> machine. See https://bugzilla.kernel.org/show_bug.cgi?id=216804#c8 for
> details (ignore the comments before that, the quirk entry for that
> machine was merged; comment 8 and all related to it really should have a
> separate bug; that's also why this partly fall through the cracks here
> :-/ ). The user is currently trying to create a patch.
>
Something I'm wondering about is if it's possible for i8042 to detect
the polarity is incorrect when it probes and
to try to correct it.
If we could do that we can probably drop 9946e39fe8d0 ("ACPI: resource:
skip IRQ override on AMD Zen platforms")
to fix this issue along with all the other quirks that have collected
over time on i8042 polarity issues.
On Wed, May 03, 2023 at 11:11:33AM -0500, Limonciello, Mario wrote:
> +linux-input
>
> On 5/3/2023 7:58 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> > Hi, Thorsten here, the Linux kernel's regression tracker.
> >
> > I noticed a regression report in bugzilla.kernel.org. As many (most?)
> > kernel developers don't keep an eye on it, I decided to forward it by mail.
> >
> > Chuanhong Guo, apparently it's cause by a change of yours.
> >
> > Note, you have to use bugzilla to reach the reporter, as I sadly[1] can
> > not CCed them in mails like this.
> >
> > Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=217394 :
> >
> > > Matthew 2023-05-03 02:28:33 UTC
> > >
> > > Reverting the changes found in this patch fixes the issue:
> > > > https://lore.kernel.org/all/[email protected]/
> > > With that patch the AT Translated Set 2 Keyboard doesn't show up with the evtest and is not usable.
> > >
> > > Hardware:
> > >
> > > Aya Neo Air Plus
> > > AMD Ryzen 7 6800U
> > See the ticket for more details.
> >
> > BTW: there apparently is another IRQ override needed for a different
> > machine. See https://bugzilla.kernel.org/show_bug.cgi?id=216804#c8 for
> > details (ignore the comments before that, the quirk entry for that
> > machine was merged; comment 8 and all related to it really should have a
> > separate bug; that's also why this partly fall through the cracks here
> > :-/ ). The user is currently trying to create a patch.
> >
> Something I'm wondering about is if it's possible for i8042 to detect the
> polarity is incorrect when it probes and
> to try to correct it.
>
> If we could do that we can probably drop 9946e39fe8d0 ("ACPI: resource: skip
> IRQ override on AMD Zen platforms")
> to fix this issue along with all the other quirks that have collected over
> time on i8042 polarity issues.
>
8042 is shared between multiple platforms and is quite fragile as it is.
If there are issues in AMD firmware and you know the polarity that is
needed for 8042 on these platforms you should add a proper fixup for
override. Maybe you should only skip override for IRQ 1?
Thanks.
--
Dmitry
On 03.05.23 21:00, Dmitry Torokhov wrote:
> On Wed, May 03, 2023 at 11:11:33AM -0500, Limonciello, Mario wrote:
>> On 5/3/2023 7:58 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>
>>> I noticed a regression report in bugzilla.kernel.org. As many (most?)
>>> kernel developers don't keep an eye on it, I decided to forward it by mail.
>>>
>>> Chuanhong Guo, apparently it's cause by a change of yours.
BTW, there is another report caused by the change:
https://bugzilla.kernel.org/show_bug.cgi?id=217406
```
I have an HP Pavilion Aero 13 laptop that comes with an AMD Ryzen 7735U
CPU and an up-to-date BIOS. Using any kernel version that is strictly
greater than 5.19.9 on it is causing the typing with the integrated
keyboard to be extremely slow. "Slow" is subjective but let's say [...]"
```
/me wonders how many machines out there show problems we never hear about
Anyway:
>>> Note, you have to use bugzilla to reach the reporter, as I sadly[1] can
>>> not CCed them in mails like this.
>>>
>>> Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=217394 :
>>>
>>>> Matthew 2023-05-03 02:28:33 UTC
>>>>
>>>> Reverting the changes found in this patch fixes the issue:
>>>>> https://lore.kernel.org/all/[email protected]/
>>>> With that patch the AT Translated Set 2 Keyboard doesn't show up with the evtest and is not usable.
>>>>
>>>> Hardware:
>>>>
>>>> Aya Neo Air Plus
>>>> AMD Ryzen 7 6800U
>>> See the ticket for more details.
>>>
>>> BTW: there apparently is another IRQ override needed for a different
>>> machine. See https://bugzilla.kernel.org/show_bug.cgi?id=216804#c8 for
>>> details (ignore the comments before that, the quirk entry for that
>>> machine was merged; comment 8 and all related to it really should have a
>>> separate bug; that's also why this partly fall through the cracks here
>>> :-/ ). The user is currently trying to create a patch.
>>>
>> Something I'm wondering about is if it's possible for i8042 to detect the
>> polarity is incorrect when it probes and
>> to try to correct it.
>>
>> If we could do that we can probably drop 9946e39fe8d0 ("ACPI: resource: skip
>> IRQ override on AMD Zen platforms")
>> to fix this issue along with all the other quirks that have collected over
>> time on i8042 polarity issues.
>
> 8042 is shared between multiple platforms and is quite fragile as it is.
> If there are issues in AMD firmware and you know the polarity that is
> needed for 8042 on these platforms you should add a proper fixup for
> override. Maybe you should only skip override for IRQ 1?
Stupid question from the peanut gallery: does anyone know what Windows
is doing on those machines? I wonder if this is one of those situation
where we just must follow suite to make things work reliably long term
for users, even if that might mean 8042 needs to be modified.
Or is the problem likely to go away with new hardware?
Ciao, Thorsten
P.S.: BTW:
#regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=217406
Hi Mario!
On Thu, May 4, 2023 at 12:11 AM Limonciello, Mario <[email protected]> wrote:
>
> +linux-input
>
> On 5/3/2023 7:58 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> > Hi, Thorsten here, the Linux kernel's regression tracker.
> >
> > I noticed a regression report in bugzilla.kernel.org. As many (most?)
> > kernel developers don't keep an eye on it, I decided to forward it by mail.
> >
> > Chuanhong Guo, apparently it's cause by a change of yours.
> >
> > Note, you have to use bugzilla to reach the reporter, as I sadly[1] can
> > not CCed them in mails like this.
> >
> > Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=217394 :
> >
> >> Matthew 2023-05-03 02:28:33 UTC
> >>
> >> Reverting the changes found in this patch fixes the issue:
> >>> https://lore.kernel.org/all/[email protected]/
> >> With that patch the AT Translated Set 2 Keyboard doesn't show up with the evtest and is not usable.
> >>
> >> Hardware:
> >>
> >> Aya Neo Air Plus
> >> AMD Ryzen 7 6800U
> > See the ticket for more details.
> >
> > BTW: there apparently is another IRQ override needed for a different
> > machine. See https://bugzilla.kernel.org/show_bug.cgi?id=216804#c8 for
> > details (ignore the comments before that, the quirk entry for that
> > machine was merged; comment 8 and all related to it really should have a
> > separate bug; that's also why this partly fall through the cracks here
> > :-/ ). The user is currently trying to create a patch.
> >
> Something I'm wondering about is if it's possible for i8042 to detect
> the polarity is incorrect when it probes and
> to try to correct it.
>
> If we could do that we can probably drop 9946e39fe8d0 ("ACPI: resource:
> skip IRQ override on AMD Zen platforms")
> to fix this issue along with all the other quirks that have collected
> over time on i8042 polarity issues.
>
I don't really understand why there are more and more new laptops
appearing with broken IRQ settings in ACPI, especially considering
the fact that some of these laptops were released after the original
problem was already identified almost a year ago.
What exactly was the solution when AMD internally discovered this IRQ
mismatch problem? Did you guys changed the emulated IRQ polarity
without updating the ACPI table with the corresponding polarity
description in your reference design?
--
Regards,
Chuanhong Guo
On 5/6/23 03:25, Chuanhong Guo wrote:
> Hi Mario!
>
> On Thu, May 4, 2023 at 12:11 AM Limonciello, Mario <[email protected]> wrote:
>> +linux-input
>>
>> On 5/3/2023 7:58 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>> Hi, Thorsten here, the Linux kernel's regression tracker.
>>>
>>> I noticed a regression report in bugzilla.kernel.org. As many (most?)
>>> kernel developers don't keep an eye on it, I decided to forward it by mail.
>>>
>>> Chuanhong Guo, apparently it's cause by a change of yours.
>>>
>>> Note, you have to use bugzilla to reach the reporter, as I sadly[1] can
>>> not CCed them in mails like this.
>>>
>>> Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=217394 :
>>>
>>>> Matthew 2023-05-03 02:28:33 UTC
>>>>
>>>> Reverting the changes found in this patch fixes the issue:
>>>>> https://lore.kernel.org/all/[email protected]/
>>>> With that patch the AT Translated Set 2 Keyboard doesn't show up with the evtest and is not usable.
>>>>
>>>> Hardware:
>>>>
>>>> Aya Neo Air Plus
>>>> AMD Ryzen 7 6800U
>>> See the ticket for more details.
>>>
>>> BTW: there apparently is another IRQ override needed for a different
>>> machine. See https://bugzilla.kernel.org/show_bug.cgi?id=216804#c8 for
>>> details (ignore the comments before that, the quirk entry for that
>>> machine was merged; comment 8 and all related to it really should have a
>>> separate bug; that's also why this partly fall through the cracks here
>>> :-/ ). The user is currently trying to create a patch.
>>>
>> Something I'm wondering about is if it's possible for i8042 to detect
>> the polarity is incorrect when it probes and
>> to try to correct it.
>>
>> If we could do that we can probably drop 9946e39fe8d0 ("ACPI: resource:
>> skip IRQ override on AMD Zen platforms")
>> to fix this issue along with all the other quirks that have collected
>> over time on i8042 polarity issues.
>>
> I don't really understand why there are more and more new laptops
> appearing with broken IRQ settings in ACPI, especially considering
> the fact that some of these laptops were released after the original
> problem was already identified almost a year ago.
> What exactly was the solution when AMD internally discovered this IRQ
> mismatch problem? Did you guys changed the emulated IRQ polarity
> without updating the ACPI table with the corresponding polarity
> description in your reference design?
>
In the reference design the tables are updated to be accurate and
reflect the appropriate polarity. It seems that the vendors must be
changing this and it not breaking Windows for some reason.
On 5/6/23 01:47, Thorsten Leemhuis wrote:
> On 03.05.23 21:00, Dmitry Torokhov wrote:
>> On Wed, May 03, 2023 at 11:11:33AM -0500, Limonciello, Mario wrote:
>>> On 5/3/2023 7:58 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>> I noticed a regression report in bugzilla.kernel.org. As many (most?)
>>>> kernel developers don't keep an eye on it, I decided to forward it by mail.
>>>>
>>>> Chuanhong Guo, apparently it's cause by a change of yours.
> BTW, there is another report caused by the change:
> https://bugzilla.kernel.org/show_bug.cgi?id=217406
>
> ```
> I have an HP Pavilion Aero 13 laptop that comes with an AMD Ryzen 7735U
> CPU and an up-to-date BIOS. Using any kernel version that is strictly
> greater than 5.19.9 on it is causing the typing with the integrated
> keyboard to be extremely slow. "Slow" is subjective but let's say [...]"
> ```
>
> /me wonders how many machines out there show problems we never hear about
>
> Anyway:
>
>>>> Note, you have to use bugzilla to reach the reporter, as I sadly[1] can
>>>> not CCed them in mails like this.
>>>>
>>>> Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=217394 :
>>>>
>>>>> Matthew 2023-05-03 02:28:33 UTC
>>>>>
>>>>> Reverting the changes found in this patch fixes the issue:
>>>>>> https://lore.kernel.org/all/[email protected]/
>>>>> With that patch the AT Translated Set 2 Keyboard doesn't show up with the evtest and is not usable.
>>>>>
>>>>> Hardware:
>>>>>
>>>>> Aya Neo Air Plus
>>>>> AMD Ryzen 7 6800U
>>>> See the ticket for more details.
>>>>
>>>> BTW: there apparently is another IRQ override needed for a different
>>>> machine. See https://bugzilla.kernel.org/show_bug.cgi?id=216804#c8 for
>>>> details (ignore the comments before that, the quirk entry for that
>>>> machine was merged; comment 8 and all related to it really should have a
>>>> separate bug; that's also why this partly fall through the cracks here
>>>> :-/ ). The user is currently trying to create a patch.
>>>>
>>> Something I'm wondering about is if it's possible for i8042 to detect the
>>> polarity is incorrect when it probes and
>>> to try to correct it.
>>>
>>> If we could do that we can probably drop 9946e39fe8d0 ("ACPI: resource: skip
>>> IRQ override on AMD Zen platforms")
>>> to fix this issue along with all the other quirks that have collected over
>>> time on i8042 polarity issues.
>> 8042 is shared between multiple platforms and is quite fragile as it is.
>> If there are issues in AMD firmware and you know the polarity that is
>> needed for 8042 on these platforms you should add a proper fixup for
>> override. Maybe you should only skip override for IRQ 1?
> Stupid question from the peanut gallery: does anyone know what Windows
> is doing on those machines? I wonder if this is one of those situation
> where we just must follow suite to make things work reliably long term
> for users, even if that might mean 8042 needs to be modified.
>
> Or is the problem likely to go away with new hardware?
>
> Ciao, Thorsten
>
> P.S.: BTW:
>
> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=217406
I've got the same question. This issue doesn't happen in AMD's
reference platform; it's not in AMD's firmware.
It seems to be happening in some OEM platforms only.
Dmitry,
Can you think about what a polarity detection scheme would look
like for i8042? If it's put in the error path (device not responding to
probe)
I would think it should be relatively low risk to otherwise working
hardware.
On the Ayaneo Air Plus I modified the DSDT based on another handheld
with a 6800U that does not have the problem and it resolved the issue. I
hope this information helps in some way.
< Name (_HID, EisaId ("PNP0303") /* IBM Enhanced Keyboard
(101/102-key, PS/2 Mouse) */) // _HID: Hardware ID
< Name (_UID, Zero) // _UID: Unique ID
---
> Name (_HID, "MSFT0001") // _HID: Hardware ID
> Name (_CID, EisaId ("PNP0303") /* IBM Enhanced Keyboard
(101/102-key, PS/2 Mouse) */) // _CID: Compatible ID
6135c6135
< IRQNoFlags ()
---
> IRQ (Edge, ActiveLow, Shared, )
On 5/7/23 7:41 AM, Mario Limonciello wrote:
>
> On 5/6/23 03:25, Chuanhong Guo wrote:
>> Hi Mario!
>>
>> On Thu, May 4, 2023 at 12:11 AM Limonciello, Mario <[email protected]>
>> wrote:
>>> +linux-input
>>>
>>> On 5/3/2023 7:58 AM, Linux regression tracking (Thorsten Leemhuis)
>>> wrote:
>>>> Hi, Thorsten here, the Linux kernel's regression tracker.
>>>>
>>>> I noticed a regression report in bugzilla.kernel.org. As many (most?)
>>>> kernel developers don't keep an eye on it, I decided to forward it
>>>> by mail.
>>>>
>>>> Chuanhong Guo, apparently it's cause by a change of yours.
>>>>
>>>> Note, you have to use bugzilla to reach the reporter, as I sadly[1]
>>>> can
>>>> not CCed them in mails like this.
>>>>
>>>> Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=217394 :
>>>>
>>>>> Matthew 2023-05-03 02:28:33 UTC
>>>>>
>>>>> Reverting the changes found in this patch fixes the issue:
>>>>>> https://lore.kernel.org/all/[email protected]/
>>>>>>
>>>>> With that patch the AT Translated Set 2 Keyboard doesn't show up
>>>>> with the evtest and is not usable.
>>>>>
>>>>> Hardware:
>>>>>
>>>>> Aya Neo Air Plus
>>>>> AMD Ryzen 7 6800U
>>>> See the ticket for more details.
>>>>
>>>> BTW: there apparently is another IRQ override needed for a different
>>>> machine. See https://bugzilla.kernel.org/show_bug.cgi?id=216804#c8 for
>>>> details (ignore the comments before that, the quirk entry for that
>>>> machine was merged; comment 8 and all related to it really should
>>>> have a
>>>> separate bug; that's also why this partly fall through the cracks here
>>>> :-/ ). The user is currently trying to create a patch.
>>>>
>>> Something I'm wondering about is if it's possible for i8042 to detect
>>> the polarity is incorrect when it probes and
>>> to try to correct it.
>>>
>>> If we could do that we can probably drop 9946e39fe8d0 ("ACPI: resource:
>>> skip IRQ override on AMD Zen platforms")
>>> to fix this issue along with all the other quirks that have collected
>>> over time on i8042 polarity issues.
>>>
>> I don't really understand why there are more and more new laptops
>> appearing with broken IRQ settings in ACPI, especially considering
>> the fact that some of these laptops were released after the original
>> problem was already identified almost a year ago.
>> What exactly was the solution when AMD internally discovered this IRQ
>> mismatch problem? Did you guys changed the emulated IRQ polarity
>> without updating the ACPI table with the corresponding polarity
>> description in your reference design?
>>
> In the reference design the tables are updated to be accurate and
> reflect the appropriate polarity. It seems that the vendors must be
> changing this and it not breaking Windows for some reason.
>
>
On Sun, May 07, 2023 at 07:45:01AM -0500, Mario Limonciello wrote:
>
> On 5/6/23 01:47, Thorsten Leemhuis wrote:
> > On 03.05.23 21:00, Dmitry Torokhov wrote:
> > > On Wed, May 03, 2023 at 11:11:33AM -0500, Limonciello, Mario wrote:
> > > > On 5/3/2023 7:58 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> > > > > I noticed a regression report in bugzilla.kernel.org. As many (most?)
> > > > > kernel developers don't keep an eye on it, I decided to forward it by mail.
> > > > >
> > > > > Chuanhong Guo, apparently it's cause by a change of yours.
> > BTW, there is another report caused by the change:
> > https://bugzilla.kernel.org/show_bug.cgi?id=217406
> >
> > ```
> > I have an HP Pavilion Aero 13 laptop that comes with an AMD Ryzen 7735U
> > CPU and an up-to-date BIOS. Using any kernel version that is strictly
> > greater than 5.19.9 on it is causing the typing with the integrated
> > keyboard to be extremely slow. "Slow" is subjective but let's say [...]"
> > ```
> >
> > /me wonders how many machines out there show problems we never hear about
> >
> > Anyway:
> >
> > > > > Note, you have to use bugzilla to reach the reporter, as I sadly[1] can
> > > > > not CCed them in mails like this.
> > > > >
> > > > > Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=217394 :
> > > > >
> > > > > > Matthew 2023-05-03 02:28:33 UTC
> > > > > >
> > > > > > Reverting the changes found in this patch fixes the issue:
> > > > > > > https://lore.kernel.org/all/[email protected]/
> > > > > > With that patch the AT Translated Set 2 Keyboard doesn't show up with the evtest and is not usable.
> > > > > >
> > > > > > Hardware:
> > > > > >
> > > > > > Aya Neo Air Plus
> > > > > > AMD Ryzen 7 6800U
> > > > > See the ticket for more details.
> > > > >
> > > > > BTW: there apparently is another IRQ override needed for a different
> > > > > machine. See https://bugzilla.kernel.org/show_bug.cgi?id=216804#c8 for
> > > > > details (ignore the comments before that, the quirk entry for that
> > > > > machine was merged; comment 8 and all related to it really should have a
> > > > > separate bug; that's also why this partly fall through the cracks here
> > > > > :-/ ). The user is currently trying to create a patch.
> > > > >
> > > > Something I'm wondering about is if it's possible for i8042 to detect the
> > > > polarity is incorrect when it probes and
> > > > to try to correct it.
> > > >
> > > > If we could do that we can probably drop 9946e39fe8d0 ("ACPI: resource: skip
> > > > IRQ override on AMD Zen platforms")
> > > > to fix this issue along with all the other quirks that have collected over
> > > > time on i8042 polarity issues.
> > > 8042 is shared between multiple platforms and is quite fragile as it is.
> > > If there are issues in AMD firmware and you know the polarity that is
> > > needed for 8042 on these platforms you should add a proper fixup for
> > > override. Maybe you should only skip override for IRQ 1?
> > Stupid question from the peanut gallery: does anyone know what Windows
> > is doing on those machines? I wonder if this is one of those situation
> > where we just must follow suite to make things work reliably long term
> > for users, even if that might mean 8042 needs to be modified.
Maybe Windows simply selects "falling edge" trigger in the driver? They
do not need to deal with multiple atchitectures, so it may work for
them.
> >
> > Or is the problem likely to go away with new hardware?
> >
> > Ciao, Thorsten
> >
> > P.S.: BTW:
> >
> > #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=217406
> I've got the same question.? This issue doesn't happen in AMD's
> reference platform; it's not in AMD's firmware.
> It seems to be happening in some OEM platforms only.
>
> Dmitry,
>
> Can you think about what a polarity detection scheme would look
> like for i8042?? If it's put in the error path (device not responding to
> probe)
> I would think it should be relatively low risk to otherwise working
> hardware.
Mario, I feel strongly that this kind of kludges belong in the platform
handling code. If you know the polarity of keyboard interrupt on AMD
platforms and that it is sometimes described incorrectly in the firmware
you should fix it up in the code that deals with the firmware.
We have some code trying to test AUX interrupt and it has all kinds of
exceptions because many ECs do not implement AUX LOOP command properly,
on some the interrupt is not delivered for the LOOP command and so
forth. It is a disaster. I shudder to think about trying to use KBD
LOOP.
Thanks.
--
Dmitry