linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>,
	"Rafael J. Wysocki" <rafael@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Len Brown <lenb@kernel.org>,
	linux-input@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Hans de Goede <hdegoede@redhat.com>
Subject: Re: i8042_init: PS/2 mouse not detected with ACPIPnP/PnPBIOS
Date: Tue, 13 Oct 2020 17:17:49 +0200	[thread overview]
Message-ID: <48973620-21a8-7fef-8c99-e59c38941145@intel.com> (raw)
In-Reply-To: <082dfba3-6187-7081-6a8c-8c38a3a95b19@molgen.mpg.de>

On 10/13/2020 5:00 PM, Paul Menzel wrote:
> Dear Rafael, dear Dmitry,
>
>
> Am 12.10.20 um 13:00 schrieb Rafael J. Wysocki:
>> On Mon, Oct 12, 2020 at 12:50 PM Paul Menzel wrote:
>
>>> Am 12.10.20 um 12:39 schrieb Rafael J. Wysocki:
>>>> On Sun, Oct 11, 2020 at 1:08 AM Paul Menzel wrote:
>
>>>>> Am 08.10.20 um 00:16 schrieb Dmitry Torokhov:
>>>>>
>>>>>> On Wed, Oct 07, 2020 at 11:18:41PM +0200, Paul Menzel wrote:
>>>>>
>>>>>>> On the Asus F2A85-M PRO Linux 5.9-rc8 (and previous versions) 
>>>>>>> does not
>>>>>>> recognize a plugged in PS/2 mouse using the Plug & Play method. 
>>>>>>> The PS/2
>>>>>>> keyboard is detected fine, and using `i8042.nopnp`, the PS/2 
>>>>>>> mouse also
>>>>>>> works.
>>>>>>>
>>>>>>>> [    1.035915] calling i8042_init+0x0/0x42d @ 1
>>>>>>>> [    1.035947] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 
>>>>>>>> 0x60,0x64 irq 1
>>>>>>>> [    1.035948] i8042: PNP: PS/2 appears to have AUX port 
>>>>>>>> disabled, if this is incorrect please boot with i8042.nopnp
>>>>>>>> [    1.036589] serio: i8042 KBD port at 0x60,0x64 irq 1
>>>>>>>> [    1.036621] initcall i8042_init+0x0/0x42d returned 0 after 
>>>>>>>> 687 usecs
>>>>>>>
>>>>>>> But, the DSDT includes the “mouse device”. From
>>>>>>>
>>>>>>>        acpidump > dump.bin; acpixtract dump.bin; iasl -d *dat; 
>>>>>>> more dsdt.dsl
>>>>>>>
>>>>>>> we get
>>>>>>>
>>>>>>>                    Device (PS2M)
>>>>>>>                    {
>>>>>>>                        Name (_HID, EisaId ("PNP0F03") /* 
>>>>>>> Microsoft PS/2-style Mouse */)  // _HID: Hardware ID
>>>>>>>                        Name (_CID, EisaId ("PNP0F13") /* PS/2 
>>>>>>> Mouse */) // _CID: Compatible ID
>>>>>>>                        Method (_STA, 0, NotSerialized)  // _STA: 
>>>>>>> Status
>>>>>>>                        {
>>>>>>>                            If ((IOST & 0x4000))
>>>>>>>                            {
>>>>>>>                                Return (0x0F)
>>>>>>>                            }
>>>>>>>                            Else
>>>>>>>                            {
>>>>>>>                                Return (Zero)
>>>>>>>                            }
>>>>>>>                        }
>>>>>>>
>>>>>>> and the identifiers PNP0F03 and PNP0F13 are both listed in the 
>>>>>>> array
>>>>>>> `pnp_aux_devids[]`. But adding print statements to 
>>>>>>> `i8042_pnp_aux_probe()`,
>>>>>>> I do not see them, so the function does not seem to be called.
>>>>>>
>>>>>> My guess is that _STA returns 0 indicating that the device is not
>>>>>> present. I would try tracking where IOST is being set and 
>>>>>> figuring out
>>>>>> why it does not have mouse bit enabled.
>>>>>
>>>>> Does the ACPI subsystem allow to track, how ACPI variables(?) like 
>>>>> IOST
>>>>> are read and set?
>>>>
>>>> My guess would be that IOST is a field in an operation region which
>>>> would indicate that it is initialized by the bootstrap part of the
>>>> BIOS.
>>>
>>> Thank you for your answer. But how can I verify that?
>>
>> Inspecting the ACPI tables from the system in question could help you
>> to find out whether or not IOST really is a field in an operation
>> region, but its initial value may not be possible to determine this
>> way.
>>
>>> Is there a Linux kernel parameter, that would print it?
>>
>> Not that I know of.
>
> I created an issue in the Linux kernel bugtracker [1] and attached the 
> output of `acpidump` there.
>
> Could
>
>     If ((IOST & 0x4000))
>
> versus
>
>     If ((IOST & 0x0400))
>
> be a typo?
>
Yes, it could.



      reply	other threads:[~2020-10-13 15:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 21:18 i8042_init: PS/2 mouse not detected with ACPIPnP/PnPBIOS Paul Menzel
2020-10-07 22:16 ` Dmitry Torokhov
2020-10-10 20:32   ` Paul Menzel
2020-10-12 10:39     ` Rafael J. Wysocki
2020-10-12 10:50       ` Paul Menzel
2020-10-12 11:00         ` Rafael J. Wysocki
2020-10-13 15:00           ` Paul Menzel
2020-10-13 15:17             ` Rafael J. Wysocki [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48973620-21a8-7fef-8c99-e59c38941145@intel.com \
    --to=rafael.j.wysocki@intel.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmenzel@molgen.mpg.de \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).