* Re: [PATCH 2/2] Input: atmel_mxt_ts - support capacitive keys
From: Linus Walleij @ 2023-03-06 22:54 UTC (permalink / raw)
To: André Apitzsch
Cc: Nick Dyer, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, linux-input,
devicetree, linux-arm-kernel, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <20230227205035.18551-2-git@apitzsch.eu>
On Mon, Feb 27, 2023 at 9:50 PM André Apitzsch <git@apitzsch.eu> wrote:
> Add support for touch keys found in some Atmel touch controller
> configurations.
>
> Signed-off-by: André Apitzsch <git@apitzsch.eu>
Looks good to me.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [GIT PULL] intel-gpio for 6.3-1
From: andy.shevchenko @ 2023-03-06 22:35 UTC (permalink / raw)
To: Linus Walleij
Cc: Andy Shevchenko, Linux GPIO, linux-arm-kernel, linux-input,
Bartosz Golaszewski, Arnd Bergmann, Dmitry Torokhov
In-Reply-To: <CACRpkdY3pCu6gZ-kA8uHAcCBpx_0AKwVLp+UyYO0dnWdt+fZKw@mail.gmail.com>
Mon, Mar 06, 2023 at 10:50:40PM +0100, Linus Walleij kirjoitti:
> On Mon, Mar 6, 2023 at 4:14 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
>
> > Hi Linux GPIO maintainers et al.,
> >
> > Combined series to clean up headers in the GPIO library and drivers.
> > Along with it, drop a few unused legacy APIs.
> >
> > This tag is immutable, enjoy!
>
> Thanks for coordinating and getting this sorted and tested Andy, perfect
> job as always!
You're welcome!
> > intel-gpio for v6.3-1
>
> But I think you mean it for v6.4?
Well, techically speaking it didn't make v6.3-rc1 due to cross-dependencies.
Starting from it it may be applied to v6.3 or to v6.4.
Up to you and Bart, but I prefer not to rebrand the tag, if it's an option.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [GIT PULL] intel-gpio for 6.3-1
From: Linus Walleij @ 2023-03-06 21:50 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Linux GPIO, linux-arm-kernel, linux-input, Bartosz Golaszewski,
Arnd Bergmann, Dmitry Torokhov
In-Reply-To: <ZAYCRPsKR8Je6LOW@black.fi.intel.com>
On Mon, Mar 6, 2023 at 4:14 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> Hi Linux GPIO maintainers et al.,
>
> Combined series to clean up headers in the GPIO library and drivers.
> Along with it, drop a few unused legacy APIs.
>
> This tag is immutable, enjoy!
Thanks for coordinating and getting this sorted and tested Andy, perfect
job as always!
> intel-gpio for v6.3-1
But I think you mean it for v6.4?
Yours,
Linus Walleij
^ permalink raw reply
* RE: "proximity" attribute for input devices
From: Limonciello, Mario @ 2023-03-06 20:43 UTC (permalink / raw)
To: Sebastian Reichel, Jason Gerecke
Cc: linux-input@vger.kernel.org, Bastien Nocera, ping.cheng@wacom.com,
jason.gerecke@wacom.com, linux-pm@vger.kernel.org
In-Reply-To: <c65e2dbc-c8f9-4481-85f1-4d1eb140a05f@mercury.local>
[Public]
> -----Original Message-----
> From: Sebastian Reichel <sebastian.reichel@collabora.com>
> Sent: Friday, March 3, 2023 19:09
> To: Jason Gerecke <killertofu@gmail.com>
> Cc: Limonciello, Mario <Mario.Limonciello@amd.com>; linux-
> input@vger.kernel.org; Bastien Nocera <hadess@hadess.net>;
> ping.cheng@wacom.com; jason.gerecke@wacom.com; linux-
> pm@vger.kernel.org
> Subject: Re: "proximity" attribute for input devices
>
> Hi,
>
> On Fri, Mar 03, 2023 at 03:05:41PM -0800, Jason Gerecke wrote:
> > Apologies for the delay in replying.
> >
> > First off: as an immediate action, I'm thinking of changing the Wacom
> > driver to do lazy creation of the power_supply device. This would mean
> > that rather than creating it at the same time as the input device, we
> > would wait until we receive some kind of affirmative indication of a
> > battery being present. Most Wacom peripherals report battery status in
> > a "heartbeat" report that is sent every few seconds, so there wouldn't
> > be much change for the typical user (just a few-second delay between
> > connecting the hardware and a power_supply device being created). In
> > the case of the "component" devices that are built into laptops and
> > other computers, however, the battery status is only reported while
> > the pen is actually in proximity. For users like you who don't own (or
> > never use) a pen, this means that our driver would never create a
> > power_supply device -- preventing GNOME from showing a battery that
> > isn't relevant. I'm working on a patch set that does this but need a
> > bit more time to finish it.
> >
> > That's only a partial solution, however. If a component user were to
> > bring a pen into prox even just briefly, then a power_supply device
> > would be created and not go away until the user reboots. The pen's
> > battery status will become stale at some point in time though --
> > self-discharge, use of the pen on another device, and even just simple
> > irrelevance if the user hasn't used the pen in a while (do I care that
> > the pen which I left at home is at 50% battery?). I agree that it
> > makes sense for userspace to hide the battery after a while due to
> > things like this. Are there new signals that the kernel should be
> > providing to userspace (e.g. an attribute that indicates if we're in
> > communication with power_supply? an attribute signaling that data
> > might be stale)? Or are the signals that are already provided
> > sufficient (e.g. should GNOME just hide power_supply devices that are
> > in an "Unknown" state? or maybe hide power_supplies which haven't
> been
> > updated in more than 1 hour?)
>
> Can't you just unregister the power-supply device if there hasn't
> been any heartbeat for some minutes and go back to the init state
> (i.e. the one where you are waiting for a heartbeat to appear for
> the first time)?
>
> > I've added the power_supply list and maintainer for some additional
> > viewpoints on the second paragraph... If there are questions about how
> > the Wacom hardware and its battery reporting works, I'm happy to
> > provide answers...
>
> I think the problem you have is quite specific to the Wacom
> hardware. Usually wireless devices are either connected or
> disconnected and drivers unregister the battery device on
> disconnect. So I think this logic belongs into Wacom specific
> code and not in generic power-supply core code.
Conceivably can the input device come and go too when in and out of
proximity? If so, you may be able to just tie the power supply creation
and destruction directly to the creation and destruction of that input
device.
^ permalink raw reply
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Andy Shevchenko @ 2023-03-06 20:36 UTC (permalink / raw)
To: Daniel Kaehn
Cc: Benjamin Tissoires, Hans de Goede, robh+dt,
krzysztof.kozlowski+dt, jikos, bartosz.golaszewski,
dmitry.torokhov, devicetree, linux-input, ethan.twardy
In-Reply-To: <CAP+ZCCfsKdOyy5vzPh5OjpZjNQrYWDRzrqa_QxvG+kZDPYa+3A@mail.gmail.com>
On Mon, Mar 06, 2023 at 01:40:16PM -0600, Daniel Kaehn wrote:
...
> Device (SE9)
> {
> Name (_ADR, 0x001D0001) // _ADR: Address
> Device (RHUB)
> {
> Name (_ADR, Zero)
> Device (CP2) // the USB-hid & CP2112 shared node
> {
> Name (_ADR, One)
> }
> }
> }
>
> If I'm understanding correctly, this adds the SE9 device as function 1
> of PCI device 0x1d,
To be precise this does not add the device. It adds a description of
the companion device in case the real one will appear on the PCI bus
with BDF 00:1d.1.
> then RHUB as the USB controller it provides, and finally, CP2 as the
> USB device attached to port 1 of the controller.
>
> With this as the loaded dsdt table, the USB device now has a firmware_node :)
> #> cat /sys/bus/usb/devices/3-1:1.0/firmware_node/path
> \_SB_.PCI0.SE9_.RHUB.CP2_
>
> After applying my patches, the HID device also references this node:
> #> cat /sys/bus/hid/devices/0003:10C4:EA90.0003/firmware_node/path
> \_SB_.PCI0.SE9_.RHUB.CP2_
>
> With this all said -- I noticed iasl prints this statement when trying
> to create a node with a lowercase name:
> "At least one lower case letter found in NameSeg, ASL is case
> insensitive - converting to upper case (GPIO)"
Yes, because it should be in the upper case.
> I wonder if this suggests that adding a call to toupper() to
> acpi_fwnode_get_named_child_node would be
> an appropriate solution for the node name casing issue....
I dunno. You need to ask in the linux-acpi@ mailing list.
To me this is corner case that can't be easily solved
(because two different specifications treat it differently.
You also need to ask DT people about capital letters there.
And my guts tell me that it's probably also carved in the spec
as "must be lower case" or alike.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Daniel Kaehn @ 2023-03-06 19:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Benjamin Tissoires, Hans de Goede, robh+dt,
krzysztof.kozlowski+dt, jikos, bartosz.golaszewski,
dmitry.torokhov, devicetree, linux-input, ethan.twardy
In-Reply-To: <ZAYca0ADk0Uk1sK1@smile.fi.intel.com>
Hello,
Sorry about the radio silence from me --
I've been trying to get this working on my end as well.
I was able to get my passed-through USB device on a qemu system to
have a firmware_node by
using the "Upgrading ACPI tables via initrd" kernel feature [1]. In
case this provides helpful information,
the below describes what I did.
This was using the default yocto core-image-minimal image and
qemu-system-x86_64.
I invoke qemu with the convenience "runqemu" script, as follows:
runqemu nographic qemuparams="
-initrd ../acpi-overlay/instrumented_initrd
-device 'usb-host,vendorid=0x10c4,productid=0xea90'
-pflash ./build/tmp/work/core2-64-poky-linux/ovmf/edk2-stable202211-r0/ovmf/ovmf.fd
"
Which invokes qemu with something like the following (sorry about the
long lines..):
qemu-system-x86_64 \
-device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 \
-netdev tap,id=net0,ifname=tap0,script=no,downscript=no \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0 \
-drive file=/home/kaehnd/src/local/x86/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20230306143252.rootfs.ext4,if=virtio,format=raw
\
-usb -device usb-tablet -usb -device usb-kbd -cpu IvyBridge \
-machine q35,i8042=off -smp 4 -m 256 \
-device 'usb-host,vendorid=0x10c4,productid=0xea90' \
-serial mon:stdio -serial null -nographic \
-kernel /home/kaehnd/src/local/x86/build/tmp/deploy/images/qemux86-64/bzImage
\
-append 'root=/dev/vda
rw ip=192.168.7.2::192.168.7.1:255.255.255.0::eth0:off:8.8.8.8
console=ttyS0 console=ttyS1 oprofile.timer=1
tsc=reliable no_timer_check rcupdate.rcu_expedited=1 '
The sysfs path tree for the CP2112 was as follows:
#> ls -l /sys/bus/hid/devices/0003:10C4:EA90.0003
lrwxrwxrwx 1 root root 0 Mar 6 19:24
/sys/bus/hid/devices/0003:10C4:EA90.0003 ->
../../../devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/0003:10C4:EA90.0003
Out of the box, firmware_node files existed only through what I assume
is the PCI bus:
/sys/devices/pci0000:00
It's ACPI path:
#> cat /sys/devices/pci0000:00/firmware_node/path
\_SB_.PCI0
Using the instructions at [1], I grabbed the dsdt table, and modified
it as follows.
Underneath the PCI0 node, I added the following ASL
```
Device (SE9)
{
Name (_ADR, 0x001D0001) // _ADR: Address
Device (RHUB)
{
Name (_ADR, Zero)
Device (CP2) // the USB-hid & CP2112 shared node
{
Name (_ADR, One)
}
}
}
```
If I'm understanding correctly, this adds the SE9 device as function 1
of PCI device 0x1d,
then RHUB as the USB controller it provides, and finally, CP2 as the
USB device attached to port 1 of the controller.
With this as the loaded dsdt table, the USB device now has a firmware_node :)
#> cat /sys/bus/usb/devices/3-1:1.0/firmware_node/path
\_SB_.PCI0.SE9_.RHUB.CP2_
After applying my patches, the HID device also references this node:
#> cat /sys/bus/hid/devices/0003:10C4:EA90.0003/firmware_node/path
\_SB_.PCI0.SE9_.RHUB.CP2_
With this all said -- I noticed iasl prints this statement when trying
to create a node with a lowercase name:
"At least one lower case letter found in NameSeg, ASL is case
insensitive - converting to upper case (GPIO)"
I wonder if this suggests that adding a call to toupper() to
acpi_fwnode_get_named_child_node would be
an appropriate solution for the node name casing issue....
[1] https://www.kernel.org/doc/html/latest/admin-guide/acpi/initrd_table_override.html
^ permalink raw reply
* [PATCH] HID: add HP 13t-aw100 & 14t-ea100 digitizer battery quirks
From: Philippe Troin @ 2023-03-06 18:18 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
Similar to many other devices using the Synopsys Designware Elantech
hardware, HP Spectre x360 13t-aw100 and 14t-ea100 report an empty
battery devices, supposedly for the active stylus.
Apply the HID_BATTERY_QUIRK_IGNORE quirk to ignore the battery reports
from these devices. Note that there are multiple versions of the panel
installed in the 14t-ea100.
Signed-off-by: Philippe Troin <phil@fifi.org>
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/hid-input.c | 6 ++++++
2 files changed, 9 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 63545cd307e5..22e716b66fb8 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -420,6 +420,9 @@
#define I2C_DEVICE_ID_SURFACE_GO_TOUCHSCREEN 0x261A
#define I2C_DEVICE_ID_SURFACE_GO2_TOUCHSCREEN 0x2A1C
#define I2C_DEVICE_ID_LENOVO_YOGA_C630_TOUCHSCREEN 0x279F
+#define I2C_DEVICE_ID_HP_SPECTRE_X360_13T_AW100 0x29F5
+#define I2C_DEVICE_ID_HP_SPECTRE_X360_14T_EA100_V1 0x2BED
+#define I2C_DEVICE_ID_HP_SPECTRE_X360_14T_EA100_V2 0x2BEE
#define USB_VENDOR_ID_ELECOM 0x056e
#define USB_DEVICE_ID_ELECOM_BM084 0x0061
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 7fc967964dd8..5c65a584b3fa 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -398,6 +398,12 @@ static const struct hid_device_id hid_battery_quirks[] = {
HID_BATTERY_QUIRK_IGNORE },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_LENOVO_YOGA_C630_TOUCHSCREEN),
HID_BATTERY_QUIRK_IGNORE },
+ { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_HP_SPECTRE_X360_13T_AW100),
+ HID_BATTERY_QUIRK_IGNORE },
+ { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_HP_SPECTRE_X360_14T_EA100_V1),
+ HID_BATTERY_QUIRK_IGNORE },
+ { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, I2C_DEVICE_ID_HP_SPECTRE_X360_14T_EA100_V2),
+ HID_BATTERY_QUIRK_IGNORE },
{}
};
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Andy Shevchenko @ 2023-03-06 17:01 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Daniel Kaehn, Hans de Goede, robh+dt, krzysztof.kozlowski+dt,
jikos, bartosz.golaszewski, dmitry.torokhov, devicetree,
linux-input, ethan.twardy
In-Reply-To: <1cab1439-77f3-6739-d4cd-5862ce8512d8@redhat.com>
On Mon, Mar 06, 2023 at 03:48:18PM +0100, Benjamin Tissoires wrote:
>
>
> On Mon, Mar 6, 2023 at 2:07 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Mon, Mar 06, 2023 at 01:36:51PM +0100, Benjamin Tissoires wrote:
> > > On Mon, Mar 6, 2023 at 11:49 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Thu, Mar 02, 2023 at 06:06:06PM +0100, Benjamin Tissoires wrote:
> > > > > On Mar 01 2023, Andy Shevchenko wrote:
> > > > > > On Tue, Feb 28, 2023 at 01:05:54PM -0600, Daniel Kaehn wrote:
> >
> > ...
> >
> > [1]: https://stackoverflow.com/a/60855157/2511795
> >
> > > > > Thanks Andy for your help here, and thanks for that link.
> > > > >
> > > > > I am trying to test Danny's patch as I want to use it for my HID CI,
> > > > > being an owner of a CP2112 device myself.
> > > > >
> > > > > The current setup is using out of the tree patches [2] which are
> > > > > implementing a platform i2c-hid support and some manual addition of a
> > > > > I2C-HID device on top of it. This works fine but gets busted every now
> > > > > and then when the tree sees a change that conflicts with these patches.
> > > > >
> > > > > So with Danny's series, I thought I could have an SSDT override to
> > > > > declare that very same device instead of patching my kernel before
> > > > > testing it.
> > > > >
> > > > > Of course, it gets tricky because I need to run that under qemu.
> > > > >
> > > > > I am currently stuck at the "sharing the firmware_node from usb with
> > > > > HID" step and I'd like to know if you could help me.
> > > > >
> > > > > On my laptop, if I plug the CP2112 (without using a USB hub), I can get:
> > > > >
> > > > > $> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
> > > > > lrwxrwxrwx. 1 root root 0 Mar 2 17:02 /sys/bus/hid/devices/0003:10C4:EA90.0079 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-9/2-9:1.0/0003:10C4:EA90.0079
> > > > > $> ls -l /sys/bus/usb/devices/2-9*/firmware_node
> > > > > lrwxrwxrwx. 1 root root 0 Mar 2 17:03 /sys/bus/usb/devices/2-9:1.0/firmware_node -> ../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:25
> > > > > lrwxrwxrwx. 1 root root 0 Mar 2 17:02 /sys/bus/usb/devices/2-9/firmware_node -> ../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:25
> > > > >
> > > > > So AFAIU the USB device is properly assigned a firmware node. My dsdt
> > > > > also shows the "Device (RHUB)" and I guess everything is fine.
> > > >
> > > > Yes, so far so good.
> > > >
> > > > > However, playing with qemu is not so easy.
> > > > >
> > > > > I am running qemu with the following arguments (well, almost because I
> > > > > have a wrapper script on top of it and I also run the compiled kernel
> > > > > from the current tree):
> > > > >
> > > > > #> qemu-system-x86_64 -bios /usr/share/edk2/ovmf/OVMF_CODE.fd \
> > > > > -netdev user,id=hostnet0 \
> > > > > -device virtio-net-pci,netdev=hostnet0 \
> > > > > -m 4G \
> > > > > -enable-kvm \
> > > > > -cpu host \
> > > > > -device qemu-xhci -usb \
> > > > > -device 'usb-host,vendorid=0x10c4,productid=0xea90' \
> > > > > -cdrom ~/Downloads/Fedora-Workstation-Live-x86_64-37-1.7.iso
> > > >
> > > > Side question, where can I get those blobs from (EDKII and Fedora Live CD)?
> > > > I'm using Debian unstable.
> > >
> > > You can install the ovmf package in debian[3], which should have a
> > > similar file.
> > > For the Fedora livecd -> https://getfedora.org/fr/workstation/download/
> > > but any other distribution with a recent enough kernel should show the
> > > same.
> >
> > Thank you!
> >
> > > > > And this is what I get:
> > > > >
> > > > > #> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
> > > > > lrwxrwxrwx 1 root root 0 Mar 2 16:10 /sys/bus/hid/devices/0003:10C4:EA90.0001 -> ../../../devices/pci0000:00/0000:00:06.0/usb2/2-1/2-1:1.0/0003:10C4:EA90.0001
> > > > >
> > > > > #> ls -l /sys/bus/usb/devices/2-1*/firmware_node
> > > > > ls: cannot access '/sys/bus/usb/devices/2-1*/firmware_node': No such file or directory
> > > > >
> > > > > Looking at the DSDT, I do not see any reference to the USB hub, so I
> > > > > wonder if the firmware_node needs to be populated first in the DSDT.
> > > >
> > > > So, where QEMU takes DSDT (ACPI tables in general) from? Can you patch that?
> > > > I believe that's the problem in qemu.
> > >
> > > That's a good question and it's one I am not sure I have the answer to.
> > > I would have assumed that the DSDT was in the OVMF firmware, but given
> > > that we can arbitrarily add command line arguments, I believe it
> > > probably just provides a baseline and then we are screwed. The OVMF bios
> > > is compiled only once, so I doubt there is any mechanism to
> > > enable/disable a component in the DSDT, or make it dynamically
> > > generated.
> >
> > We have two ways of filling missing parts:
> > 1) update the original source of DSDT (firmware or bootloader,
> > whichever provides that);
> > 2) adding an overlay.
> >
> > The 2) works _if and only if_ there is *no* existing object in the tables.
> > In such cases, you can simply provide a *full* hierarchy. See an example of
> > PCI devices in the kernel documentation on how to do that. I believe something
> > similar can be done for USB.
>
> Please find attached the dsdt from the Qemu VM.
Thank you!
> And after looking at it, your comments below, I think I am understanding
> what is happening (on the qemu side at least):
>
> #> grep PCI0.S /sys/bus/acpi/devices/*/path
> /sys/bus/acpi/devices/device:02/path:\_SB_.PCI0.S00_
> /sys/bus/acpi/devices/device:03/path:\_SB_.PCI0.S10_
> /sys/bus/acpi/devices/device:04/path:\_SB_.PCI0.S18_
> /sys/bus/acpi/devices/device:05/path:\_SB_.PCI0.S20_
> /sys/bus/acpi/devices/device:06/path:\_SB_.PCI0.S28_
> /sys/bus/acpi/devices/device:07/path:\_SB_.PCI0.S30_
> /sys/bus/acpi/devices/device:08/path:\_SB_.PCI0.S38_
> /sys/bus/acpi/devices/device:09/path:\_SB_.PCI0.S40_
> /sys/bus/acpi/devices/device:0a/path:\_SB_.PCI0.S48_
> /sys/bus/acpi/devices/device:0b/path:\_SB_.PCI0.S50_
> /sys/bus/acpi/devices/device:0c/path:\_SB_.PCI0.S58_
> /sys/bus/acpi/devices/device:0d/path:\_SB_.PCI0.S60_
> /sys/bus/acpi/devices/device:0e/path:\_SB_.PCI0.S68_
> /sys/bus/acpi/devices/device:0f/path:\_SB_.PCI0.S70_
> /sys/bus/acpi/devices/device:10/path:\_SB_.PCI0.S78_
> /sys/bus/acpi/devices/device:11/path:\_SB_.PCI0.S80_
> /sys/bus/acpi/devices/device:12/path:\_SB_.PCI0.S88_
> /sys/bus/acpi/devices/device:13/path:\_SB_.PCI0.S90_
> /sys/bus/acpi/devices/device:14/path:\_SB_.PCI0.S98_
> /sys/bus/acpi/devices/device:15/path:\_SB_.PCI0.SA0_
> /sys/bus/acpi/devices/device:16/path:\_SB_.PCI0.SA8_
> /sys/bus/acpi/devices/device:17/path:\_SB_.PCI0.SB0_
> /sys/bus/acpi/devices/device:18/path:\_SB_.PCI0.SB8_
> /sys/bus/acpi/devices/device:19/path:\_SB_.PCI0.SC0_
> /sys/bus/acpi/devices/device:1a/path:\_SB_.PCI0.SC8_
> /sys/bus/acpi/devices/device:1b/path:\_SB_.PCI0.SD0_
> /sys/bus/acpi/devices/device:1c/path:\_SB_.PCI0.SD8_
> /sys/bus/acpi/devices/device:1d/path:\_SB_.PCI0.SE0_
> /sys/bus/acpi/devices/device:1e/path:\_SB_.PCI0.SE8_
> /sys/bus/acpi/devices/device:1f/path:\_SB_.PCI0.SF0_
> /sys/bus/acpi/devices/device:20/path:\_SB_.PCI0.SF8_
Ah, not much to get out of it.
From DSDT _ADR() you may deduct the PCI BDF of each device in the topology.
> And those translate on the DSDT as (for the S30/S38 chunk I am
> interested in):
>
> Device (S30)
> {
> Name (_ADR, 0x00060000) // _ADR: Address
In PCI this is 00:06.0
> Name (ASUN, 0x06)
> Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
> {
> Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
> }
>
> Name (_SUN, 0x06) // _SUN: Slot User Number
> Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
> {
> PCEJ (BSEL, _SUN)
> }
> }
>
> Device (S38)
> {
> Name (_ADR, 0x00070000) // _ADR: Address
00:07.0 respectively.
> Name (ASUN, 0x07)
> Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
> {
> Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
> }
>
> Name (_SUN, 0x07) // _SUN: Slot User Number
> Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
> {
> PCEJ (BSEL, _SUN)
> }
> }
>
> The forwarded USB node is actually on device:07 -> S30_, and as much as
> I'd like it to be a regular USB hub, this looks like a virtio node entry
> that allows to forward a physical device to the VM.
>
> So IMO, the missing piece might rely on the virtio-usb code which
> doesn't export the firmware node, which means I can not extend the
> device with an SSDT overlay ATM because the USB node doesn't have the
> fw_node.
Ah, that very much may explain this!
> > > > > Also note that if I plug the CP2112 over a docking station, I lose the
> > > > > firmware_node sysfs entries on the host too.
> > > >
> > > > This seems like a lack of firmware node propagating in the USB hub code in
> > > > the Linux kernel.
> > >
> > > That would make a lot of sense.
> > >
> > > FWIW, in the VM I see a firmware node on the pci controller itself:
> > > #> ls -l /sys/devices/pci0000\:00/0000\:00\:06.0/firmware_node
> > > lrwxrwxrwx 1 root root 0 Mar 6 12:24 /sys/devices/pci0000:00/0000:00:06.0/firmware_node -> ../../LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07
> > >
> > > And one the host, through a USB hub:
> > >
> > > #> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
> > > lrwxrwxrwx. 1 root root 0 Mar 6 13:26 /sys/bus/hid/devices/0003:10C4:EA90.007C -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-8/2-8.2/2-8.2.4/2-8.2.4:1.0/0003:10C4:EA90.007C
> > > #> ls -l /sys/bus/usb/devices/2-8*/firmware_node
> > > lrwxrwxrwx. 1 root root 0 Mar 2 16:53 /sys/bus/usb/devices/2-8:1.0/firmware_node -> ../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:1e
> > > lrwxrwxrwx. 1 root root 0 Mar 2 16:53 /sys/bus/usb/devices/2-8/firmware_node -> ../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:1e
> > >
> > > Note that the firmware node propagation stopped at 2-8, and 2.8.2 is not
> > > having a firmware node.
> >
> > It would be nice if you can run `grep -H 15 /sys/bus/acpi/devices/*/status`,
>
> This command (both on the host and on the VM) does not show any USB
> device or even the PCI USB controller itself (PNP0A08 or PNP0A03).
>
> > filter out unneeded ones, and for the rest also print their paths:
> > `cat filtered_list_of_acpi_devs | while read p; do grep -H . $p/path; done`
>
> see above for the VM case, and in the host:
>
> #> grep XHC /sys/bus/acpi/devices/*/path
> /sys/bus/acpi/devices/device:15/path:\_SB_.PCI0.XHC_
> /sys/bus/acpi/devices/device:16/path:\_SB_.PCI0.XHC_.RHUB
> /sys/bus/acpi/devices/device:17/path:\_SB_.PCI0.XHC_.RHUB.HS01
> /sys/bus/acpi/devices/device:18/path:\_SB_.PCI0.XHC_.RHUB.HS02
> /sys/bus/acpi/devices/device:19/path:\_SB_.PCI0.XHC_.RHUB.HS03
> /sys/bus/acpi/devices/device:1a/path:\_SB_.PCI0.XHC_.RHUB.HS04
> /sys/bus/acpi/devices/device:1b/path:\_SB_.PCI0.XHC_.RHUB.HS05
> /sys/bus/acpi/devices/device:1c/path:\_SB_.PCI0.XHC_.RHUB.HS06
> /sys/bus/acpi/devices/device:1d/path:\_SB_.PCI0.XHC_.RHUB.HS07
> /sys/bus/acpi/devices/device:1e/path:\_SB_.PCI0.XHC_.RHUB.HS08
> /sys/bus/acpi/devices/device:1f/path:\_SB_.PCI0.XHC_.RHUB.SS01
> /sys/bus/acpi/devices/device:20/path:\_SB_.PCI0.XHC_.RHUB.SS02
> /sys/bus/acpi/devices/device:21/path:\_SB_.PCI0.XHC_.RHUB.SS03
> /sys/bus/acpi/devices/device:22/path:\_SB_.PCI0.XHC_.RHUB.SS04
> /sys/bus/acpi/devices/device:23/path:\_SB_.PCI0.XHC_.RHUB.SS05
> /sys/bus/acpi/devices/device:24/path:\_SB_.PCI0.XHC_.RHUB.SS06
> /sys/bus/acpi/devices/device:25/path:\_SB_.PCI0.XHC_.RHUB.HS09
> /sys/bus/acpi/devices/device:26/path:\_SB_.PCI0.XHC_.RHUB.HS10
> /sys/bus/acpi/devices/device:27/path:\_SB_.PCI0.XHC_.RHUB.USR1
> /sys/bus/acpi/devices/device:28/path:\_SB_.PCI0.XHC_.RHUB.USR2
> /sys/bus/acpi/devices/device:85/path:\_SB_.PCI0.TXHC
> /sys/bus/acpi/devices/device:86/path:\_SB_.PCI0.TXHC.RHUB
> /sys/bus/acpi/devices/device:87/path:\_SB_.PCI0.TXHC.RHUB.HS01
> /sys/bus/acpi/devices/device:88/path:\_SB_.PCI0.TXHC.RHUB.SS01
> /sys/bus/acpi/devices/device:89/path:\_SB_.PCI0.TXHC.RHUB.SS02
> /sys/bus/acpi/devices/device:8a/path:\_SB_.PCI0.TXHC.RHUB.SS03
> /sys/bus/acpi/devices/device:8b/path:\_SB_.PCI0.TXHC.RHUB.SS04
>
> Which is coherent with the ../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:1e
> I get when looking at the USB port.
>
> > With this we will see what devices are actually present and up and running
> > in the system and what their paths in the ACPI namespace.
>
> So it seems that the USB hub functionality is not creating fw_nodes for
> its children. But I am not sure this is a battle we want to fight right
> now, because it doesn't make a lot of sense IMO to add an SSDT overlay
> on a hub.
The description of the attachable devices should really be in the overlays
if user wants them, but it's another story.
> > > > > Do you think it would be achievable to emulate that over qemu and use a
> > > > > mainline kernel without patches?
> > > >
> > > > As long as qemu provides correct DSDT it should work I assume.
> > >
> > > Just to be sure I understand, for this to work, we need the DSDT to
> > > export a "Device(RHUB)"?
> >
> > Not sure I understand the term "export" here. We need a description
> > of the (to describe) missing parts.
>
> Yes, I meant "to describe" it.
>
> > > Or if we fix the USB fw_node propagation, could we just overwrite
> > > "\_SB_.PCI0.S30_"? "\_SB_.PCI0.S30_" is the name the ACPI is giving to
> > > the USB port in my VM case AFAIU.
> >
> > I have no idea what is the S30 node.
>
> That gave me the hint I needed, I think. The problem must be in the
> virtio drivers, where it doesn't attach the fw_node to the components it
> creates. We probably need kind of the same patch Danny is sending in 2/3
> in this series, but for virtio.
Sounds like that, indeed.
> > [2] https://gitlab.freedesktop.org/bentiss/gitlab-kernel-ci/-/tree/master/VM
> > [3] https://packages.debian.org/buster/all/ovmf/filelist
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [GIT PULL] intel-gpio for 6.3-1
From: Andy Shevchenko @ 2023-03-06 15:09 UTC (permalink / raw)
To: Linux GPIO, linux-arm-kernel, linux-input
Cc: Linus Walleij, Bartosz Golaszewski, Andy Shevchenko,
Arnd Bergmann, Dmitry Torokhov
Hi Linux GPIO maintainers et al.,
Combined series to clean up headers in the GPIO library and drivers.
Along with it, drop a few unused legacy APIs.
This tag is immutable, enjoy!
Thanks,
With Best Regards,
Andy Shevchenko
The following changes since commit fe15c26ee26efa11741a7b632e9f23b01aca4cc6:
Linux 6.3-rc1 (2023-03-05 14:52:03 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel.git tags/intel-gpio-v6.3-1
for you to fetch changes up to 380c7ba3923c6e471aff0f951a6cf42e8dec2c79:
gpiolib: Clean up headers (2023-03-06 12:33:02 +0200)
----------------------------------------------------------------
intel-gpio for v6.3-1
* Remove some of the legacy APIs that are not used anymore
* Clean up headers in the GPIO library and drivers
The following is an automated git shortlog grouped by driver:
aggregator:
- Add missing header(s)
ARM:
- s3c64xx: Use the right include
- orion/gpio: Use the right include
gpiolib:
- Clean up headers
- Group forward declarations in consumer.h
- Deduplicate forward declarations in consumer.h
- Drop unused forward declaration from driver.h
- split of_mm_gpio_chip out of linux/of_gpio.h
- split linux/gpio/driver.h out of linux/gpio.h
- remove legacy gpio_export()
- remove gpio_set_debounce()
- remove asm-generic/gpio.h
- coldfire: remove custom asm/gpio.h
- remove empty asm/gpio.h files
- Make the legacy <linux/gpio.h> consumer-only
hte:
- tegra-194: Use proper includes
reg:
- Add missing header(s)
regmap:
- Add missing header(s)
----------------------------------------------------------------
Andy Shevchenko (7):
gpio: aggregator: Add missing header(s)
gpio: reg: Add missing header(s)
gpio: regmap: Add missing header(s)
gpiolib: Drop unused forward declaration from driver.h
gpiolib: Deduplicate forward declarations in consumer.h
gpiolib: Group forward declarations in consumer.h
gpiolib: Clean up headers
Arnd Bergmann (7):
gpiolib: remove empty asm/gpio.h files
gpiolib: coldfire: remove custom asm/gpio.h
gpiolib: remove asm-generic/gpio.h
gpiolib: remove gpio_set_debounce()
gpiolib: remove legacy gpio_export()
gpiolib: split linux/gpio/driver.h out of linux/gpio.h
gpiolib: split of_mm_gpio_chip out of linux/of_gpio.h
Linus Walleij (4):
ARM: orion/gpio: Use the right include
ARM: s3c64xx: Use the right include
hte: tegra-194: Use proper includes
gpiolib: Make the legacy <linux/gpio.h> consumer-only
Documentation/admin-guide/gpio/sysfs.rst | 2 +-
Documentation/driver-api/gpio/legacy.rst | 23 ----
.../translations/zh_CN/driver-api/gpio/legacy.rst | 20 ---
Documentation/translations/zh_TW/gpio.txt | 19 ---
MAINTAINERS | 1 -
arch/arm/Kconfig | 1 -
arch/arm/include/asm/gpio.h | 21 ---
arch/arm/mach-omap1/irq.c | 1 +
arch/arm/mach-omap2/pdata-quirks.c | 9 +-
arch/arm/mach-orion5x/board-rd88f5182.c | 1 +
arch/arm/mach-s3c/s3c64xx.c | 2 +-
arch/arm/mach-sa1100/assabet.c | 1 +
arch/arm/plat-orion/gpio.c | 5 +-
arch/m68k/Kconfig.cpu | 1 -
arch/m68k/include/asm/gpio.h | 95 -------------
arch/m68k/include/asm/mcfgpio.h | 2 +-
arch/powerpc/platforms/44x/Kconfig | 1 +
arch/powerpc/platforms/4xx/gpio.c | 2 +-
arch/powerpc/platforms/8xx/Kconfig | 1 +
arch/powerpc/platforms/8xx/cpm1.c | 2 +-
arch/powerpc/platforms/Kconfig | 2 +
arch/powerpc/sysdev/cpm_common.c | 2 +-
arch/sh/Kconfig | 1 -
arch/sh/boards/board-magicpanelr2.c | 1 +
arch/sh/boards/mach-ap325rxa/setup.c | 7 +-
arch/sh/include/asm/gpio.h | 45 -------
drivers/gpio/Kconfig | 19 +--
drivers/gpio/TODO | 15 ++-
drivers/gpio/gpio-aggregator.c | 9 +-
drivers/gpio/gpio-altera.c | 2 +-
drivers/gpio/gpio-davinci.c | 2 -
drivers/gpio/gpio-mm-lantiq.c | 2 +-
drivers/gpio/gpio-mpc5200.c | 2 +-
drivers/gpio/gpio-reg.c | 12 +-
drivers/gpio/gpio-regmap.c | 12 +-
drivers/gpio/gpiolib-acpi.c | 10 +-
drivers/gpio/gpiolib-acpi.h | 1 -
drivers/gpio/gpiolib-of.c | 9 +-
drivers/gpio/gpiolib-of.h | 1 -
drivers/gpio/gpiolib-swnode.c | 5 +-
drivers/gpio/gpiolib-sysfs.c | 25 +++-
drivers/gpio/gpiolib.c | 9 +-
drivers/hte/hte-tegra194-test.c | 10 +-
drivers/input/touchscreen/ads7846.c | 5 +-
drivers/media/pci/sta2x11/sta2x11_vip.c | 10 +-
drivers/net/ieee802154/ca8210.c | 3 +-
.../net/wireless/broadcom/brcm80211/brcmsmac/led.c | 1 +
drivers/pinctrl/core.c | 1 -
drivers/soc/fsl/qe/gpio.c | 2 +-
include/asm-generic/gpio.h | 147 ---------------------
include/linux/gpio.h | 104 +++++++++------
include/linux/gpio/consumer.h | 24 ++--
include/linux/gpio/driver.h | 31 +++--
include/linux/gpio/legacy-of-mm-gpiochip.h | 36 +++++
include/linux/mfd/ucb1x00.h | 1 +
include/linux/of_gpio.h | 21 ---
56 files changed, 271 insertions(+), 528 deletions(-)
delete mode 100644 arch/arm/include/asm/gpio.h
delete mode 100644 arch/m68k/include/asm/gpio.h
delete mode 100644 arch/sh/include/asm/gpio.h
delete mode 100644 include/asm-generic/gpio.h
create mode 100644 include/linux/gpio/legacy-of-mm-gpiochip.h
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Benjamin Tissoires @ 2023-03-06 14:48 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Daniel Kaehn, Hans de Goede, robh+dt, krzysztof.kozlowski+dt,
jikos, bartosz.golaszewski, dmitry.torokhov, devicetree,
linux-input, ethan.twardy
In-Reply-To: <ZAXlh9ZVjGJh0l7n@smile.fi.intel.com>
[-- Attachment #1: Type: text/plain, Size: 13762 bytes --]
On Mon, Mar 6, 2023 at 2:07 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Mar 06, 2023 at 01:36:51PM +0100, Benjamin Tissoires wrote:
> > On Mon, Mar 6, 2023 at 11:49 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > > On Thu, Mar 02, 2023 at 06:06:06PM +0100, Benjamin Tissoires wrote:
> > > > On Mar 01 2023, Andy Shevchenko wrote:
> > > > > On Tue, Feb 28, 2023 at 01:05:54PM -0600, Daniel Kaehn wrote:
>
> ...
>
> [1]: https://stackoverflow.com/a/60855157/2511795
>
> > > > Thanks Andy for your help here, and thanks for that link.
> > > >
> > > > I am trying to test Danny's patch as I want to use it for my HID CI,
> > > > being an owner of a CP2112 device myself.
> > > >
> > > > The current setup is using out of the tree patches [2] which are
> > > > implementing a platform i2c-hid support and some manual addition of a
> > > > I2C-HID device on top of it. This works fine but gets busted every now
> > > > and then when the tree sees a change that conflicts with these patches.
> > > >
> > > > So with Danny's series, I thought I could have an SSDT override to
> > > > declare that very same device instead of patching my kernel before
> > > > testing it.
> > > >
> > > > Of course, it gets tricky because I need to run that under qemu.
> > > >
> > > > I am currently stuck at the "sharing the firmware_node from usb with
> > > > HID" step and I'd like to know if you could help me.
> > > >
> > > > On my laptop, if I plug the CP2112 (without using a USB hub), I can get:
> > > >
> > > > $> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
> > > > lrwxrwxrwx. 1 root root 0 Mar 2 17:02 /sys/bus/hid/devices/0003:10C4:EA90.0079 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-9/2-9:1.0/0003:10C4:EA90.0079
> > > > $> ls -l /sys/bus/usb/devices/2-9*/firmware_node
> > > > lrwxrwxrwx. 1 root root 0 Mar 2 17:03 /sys/bus/usb/devices/2-9:1.0/firmware_node -> ../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:25
> > > > lrwxrwxrwx. 1 root root 0 Mar 2 17:02 /sys/bus/usb/devices/2-9/firmware_node -> ../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:25
> > > >
> > > > So AFAIU the USB device is properly assigned a firmware node. My dsdt
> > > > also shows the "Device (RHUB)" and I guess everything is fine.
> > >
> > > Yes, so far so good.
> > >
> > > > However, playing with qemu is not so easy.
> > > >
> > > > I am running qemu with the following arguments (well, almost because I
> > > > have a wrapper script on top of it and I also run the compiled kernel
> > > > from the current tree):
> > > >
> > > > #> qemu-system-x86_64 -bios /usr/share/edk2/ovmf/OVMF_CODE.fd \
> > > > -netdev user,id=hostnet0 \
> > > > -device virtio-net-pci,netdev=hostnet0 \
> > > > -m 4G \
> > > > -enable-kvm \
> > > > -cpu host \
> > > > -device qemu-xhci -usb \
> > > > -device 'usb-host,vendorid=0x10c4,productid=0xea90' \
> > > > -cdrom ~/Downloads/Fedora-Workstation-Live-x86_64-37-1.7.iso
> > >
> > > Side question, where can I get those blobs from (EDKII and Fedora Live CD)?
> > > I'm using Debian unstable.
> >
> > You can install the ovmf package in debian[3], which should have a
> > similar file.
> > For the Fedora livecd -> https://getfedora.org/fr/workstation/download/
> > but any other distribution with a recent enough kernel should show the
> > same.
>
> Thank you!
>
> > > > And this is what I get:
> > > >
> > > > #> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
> > > > lrwxrwxrwx 1 root root 0 Mar 2 16:10 /sys/bus/hid/devices/0003:10C4:EA90.0001 -> ../../../devices/pci0000:00/0000:00:06.0/usb2/2-1/2-1:1.0/0003:10C4:EA90.0001
> > > >
> > > > #> ls -l /sys/bus/usb/devices/2-1*/firmware_node
> > > > ls: cannot access '/sys/bus/usb/devices/2-1*/firmware_node': No such file or directory
> > > >
> > > > Looking at the DSDT, I do not see any reference to the USB hub, so I
> > > > wonder if the firmware_node needs to be populated first in the DSDT.
> > >
> > > So, where QEMU takes DSDT (ACPI tables in general) from? Can you patch that?
> > > I believe that's the problem in qemu.
> >
> > That's a good question and it's one I am not sure I have the answer to.
> > I would have assumed that the DSDT was in the OVMF firmware, but given
> > that we can arbitrarily add command line arguments, I believe it
> > probably just provides a baseline and then we are screwed. The OVMF bios
> > is compiled only once, so I doubt there is any mechanism to
> > enable/disable a component in the DSDT, or make it dynamically
> > generated.
>
> We have two ways of filling missing parts:
> 1) update the original source of DSDT (firmware or bootloader,
> whichever provides that);
> 2) adding an overlay.
>
> The 2) works _if and only if_ there is *no* existing object in the tables.
> In such cases, you can simply provide a *full* hierarchy. See an example of
> PCI devices in the kernel documentation on how to do that. I believe something
> similar can be done for USB.
Please find attached the dsdt from the Qemu VM.
And after looking at it, your comments below, I think I am understanding
what is happening (on the qemu side at least):
#> grep PCI0.S /sys/bus/acpi/devices/*/path
/sys/bus/acpi/devices/device:02/path:\_SB_.PCI0.S00_
/sys/bus/acpi/devices/device:03/path:\_SB_.PCI0.S10_
/sys/bus/acpi/devices/device:04/path:\_SB_.PCI0.S18_
/sys/bus/acpi/devices/device:05/path:\_SB_.PCI0.S20_
/sys/bus/acpi/devices/device:06/path:\_SB_.PCI0.S28_
/sys/bus/acpi/devices/device:07/path:\_SB_.PCI0.S30_
/sys/bus/acpi/devices/device:08/path:\_SB_.PCI0.S38_
/sys/bus/acpi/devices/device:09/path:\_SB_.PCI0.S40_
/sys/bus/acpi/devices/device:0a/path:\_SB_.PCI0.S48_
/sys/bus/acpi/devices/device:0b/path:\_SB_.PCI0.S50_
/sys/bus/acpi/devices/device:0c/path:\_SB_.PCI0.S58_
/sys/bus/acpi/devices/device:0d/path:\_SB_.PCI0.S60_
/sys/bus/acpi/devices/device:0e/path:\_SB_.PCI0.S68_
/sys/bus/acpi/devices/device:0f/path:\_SB_.PCI0.S70_
/sys/bus/acpi/devices/device:10/path:\_SB_.PCI0.S78_
/sys/bus/acpi/devices/device:11/path:\_SB_.PCI0.S80_
/sys/bus/acpi/devices/device:12/path:\_SB_.PCI0.S88_
/sys/bus/acpi/devices/device:13/path:\_SB_.PCI0.S90_
/sys/bus/acpi/devices/device:14/path:\_SB_.PCI0.S98_
/sys/bus/acpi/devices/device:15/path:\_SB_.PCI0.SA0_
/sys/bus/acpi/devices/device:16/path:\_SB_.PCI0.SA8_
/sys/bus/acpi/devices/device:17/path:\_SB_.PCI0.SB0_
/sys/bus/acpi/devices/device:18/path:\_SB_.PCI0.SB8_
/sys/bus/acpi/devices/device:19/path:\_SB_.PCI0.SC0_
/sys/bus/acpi/devices/device:1a/path:\_SB_.PCI0.SC8_
/sys/bus/acpi/devices/device:1b/path:\_SB_.PCI0.SD0_
/sys/bus/acpi/devices/device:1c/path:\_SB_.PCI0.SD8_
/sys/bus/acpi/devices/device:1d/path:\_SB_.PCI0.SE0_
/sys/bus/acpi/devices/device:1e/path:\_SB_.PCI0.SE8_
/sys/bus/acpi/devices/device:1f/path:\_SB_.PCI0.SF0_
/sys/bus/acpi/devices/device:20/path:\_SB_.PCI0.SF8_
And those translate on the DSDT as (for the S30/S38 chunk I am
interested in):
Device (S30)
{
Name (_ADR, 0x00060000) // _ADR: Address
Name (ASUN, 0x06)
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
}
Name (_SUN, 0x06) // _SUN: Slot User Number
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
}
Device (S38)
{
Name (_ADR, 0x00070000) // _ADR: Address
Name (ASUN, 0x07)
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
}
Name (_SUN, 0x07) // _SUN: Slot User Number
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
}
The forwarded USB node is actually on device:07 -> S30_, and as much as
I'd like it to be a regular USB hub, this looks like a virtio node entry
that allows to forward a physical device to the VM.
So IMO, the missing piece might rely on the virtio-usb code which
doesn't export the firmware node, which means I can not extend the
device with an SSDT overlay ATM because the USB node doesn't have the
fw_node.
>
> > > > Also note that if I plug the CP2112 over a docking station, I lose the
> > > > firmware_node sysfs entries on the host too.
> > >
> > > This seems like a lack of firmware node propagating in the USB hub code in
> > > the Linux kernel.
> >
> > That would make a lot of sense.
> >
> > FWIW, in the VM I see a firmware node on the pci controller itself:
> > #> ls -l /sys/devices/pci0000\:00/0000\:00\:06.0/firmware_node
> > lrwxrwxrwx 1 root root 0 Mar 6 12:24 /sys/devices/pci0000:00/0000:00:06.0/firmware_node -> ../../LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07
> >
> > And one the host, through a USB hub:
> >
> > #> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
> > lrwxrwxrwx. 1 root root 0 Mar 6 13:26 /sys/bus/hid/devices/0003:10C4:EA90.007C -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-8/2-8.2/2-8.2.4/2-8.2.4:1.0/0003:10C4:EA90.007C
> > #> ls -l /sys/bus/usb/devices/2-8*/firmware_node
> > lrwxrwxrwx. 1 root root 0 Mar 2 16:53 /sys/bus/usb/devices/2-8:1.0/firmware_node -> ../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:1e
> > lrwxrwxrwx. 1 root root 0 Mar 2 16:53 /sys/bus/usb/devices/2-8/firmware_node -> ../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:1e
> >
> > Note that the firmware node propagation stopped at 2-8, and 2.8.2 is not
> > having a firmware node.
>
> It would be nice if you can run `grep -H 15 /sys/bus/acpi/devices/*/status`,
This command (both on the host and on the VM) does not show any USB
device or even the PCI USB controller itself (PNP0A08 or PNP0A03).
> filter out unneeded ones, and for the rest also print their paths:
> `cat filtered_list_of_acpi_devs | while read p; do grep -H . $p/path; done`
see above for the VM case, and in the host:
#> grep XHC /sys/bus/acpi/devices/*/path
/sys/bus/acpi/devices/device:15/path:\_SB_.PCI0.XHC_
/sys/bus/acpi/devices/device:16/path:\_SB_.PCI0.XHC_.RHUB
/sys/bus/acpi/devices/device:17/path:\_SB_.PCI0.XHC_.RHUB.HS01
/sys/bus/acpi/devices/device:18/path:\_SB_.PCI0.XHC_.RHUB.HS02
/sys/bus/acpi/devices/device:19/path:\_SB_.PCI0.XHC_.RHUB.HS03
/sys/bus/acpi/devices/device:1a/path:\_SB_.PCI0.XHC_.RHUB.HS04
/sys/bus/acpi/devices/device:1b/path:\_SB_.PCI0.XHC_.RHUB.HS05
/sys/bus/acpi/devices/device:1c/path:\_SB_.PCI0.XHC_.RHUB.HS06
/sys/bus/acpi/devices/device:1d/path:\_SB_.PCI0.XHC_.RHUB.HS07
/sys/bus/acpi/devices/device:1e/path:\_SB_.PCI0.XHC_.RHUB.HS08
/sys/bus/acpi/devices/device:1f/path:\_SB_.PCI0.XHC_.RHUB.SS01
/sys/bus/acpi/devices/device:20/path:\_SB_.PCI0.XHC_.RHUB.SS02
/sys/bus/acpi/devices/device:21/path:\_SB_.PCI0.XHC_.RHUB.SS03
/sys/bus/acpi/devices/device:22/path:\_SB_.PCI0.XHC_.RHUB.SS04
/sys/bus/acpi/devices/device:23/path:\_SB_.PCI0.XHC_.RHUB.SS05
/sys/bus/acpi/devices/device:24/path:\_SB_.PCI0.XHC_.RHUB.SS06
/sys/bus/acpi/devices/device:25/path:\_SB_.PCI0.XHC_.RHUB.HS09
/sys/bus/acpi/devices/device:26/path:\_SB_.PCI0.XHC_.RHUB.HS10
/sys/bus/acpi/devices/device:27/path:\_SB_.PCI0.XHC_.RHUB.USR1
/sys/bus/acpi/devices/device:28/path:\_SB_.PCI0.XHC_.RHUB.USR2
/sys/bus/acpi/devices/device:85/path:\_SB_.PCI0.TXHC
/sys/bus/acpi/devices/device:86/path:\_SB_.PCI0.TXHC.RHUB
/sys/bus/acpi/devices/device:87/path:\_SB_.PCI0.TXHC.RHUB.HS01
/sys/bus/acpi/devices/device:88/path:\_SB_.PCI0.TXHC.RHUB.SS01
/sys/bus/acpi/devices/device:89/path:\_SB_.PCI0.TXHC.RHUB.SS02
/sys/bus/acpi/devices/device:8a/path:\_SB_.PCI0.TXHC.RHUB.SS03
/sys/bus/acpi/devices/device:8b/path:\_SB_.PCI0.TXHC.RHUB.SS04
Which is coherent with the ../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:1e
I get when looking at the USB port.
>
> With this we will see what devices are actually present and up and running
> in the system and what their paths in the ACPI namespace.
So it seems that the USB hub functionality is not creating fw_nodes for
its children. But I am not sure this is a battle we want to fight right
now, because it doesn't make a lot of sense IMO to add an SSDT overlay
on a hub.
>
> > > > Do you think it would be achievable to emulate that over qemu and use a
> > > > mainline kernel without patches?
> > >
> > > As long as qemu provides correct DSDT it should work I assume.
> >
> > Just to be sure I understand, for this to work, we need the DSDT to
> > export a "Device(RHUB)"?
>
> Not sure I understand the term "export" here. We need a description
> of the (to describe) missing parts.
Yes, I meant "to describe" it.
>
> > Or if we fix the USB fw_node propagation, could we just overwrite
> > "\_SB_.PCI0.S30_"? "\_SB_.PCI0.S30_" is the name the ACPI is giving to
> > the USB port in my VM case AFAIU.
>
> I have no idea what is the S30 node.
That gave me the hint I needed, I think. The problem must be in the
virtio drivers, where it doesn't attach the fw_node to the components it
creates. We probably need kind of the same patch Danny is sending in 2/3
in this series, but for virtio.
Cheers,
Benjamin
>
> [2] https://gitlab.freedesktop.org/bentiss/gitlab-kernel-ci/-/tree/master/VM
> [3] https://packages.debian.org/buster/all/ovmf/filelist
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
[-- Attachment #2: dsdt.dsl --]
[-- Type: text/x-dsl, Size: 49650 bytes --]
/*
* Intel ACPI Component Architecture
* AML/ASL+ Disassembler version 20220331 (64-bit version)
* Copyright (c) 2000 - 2022 Intel Corporation
*
* Disassembling to symbolic ASL+ operators
*
* Disassembly of dsdt.dat, Thu Mar 2 15:16:39 2023
*
* Original Table Header:
* Signature "DSDT"
* Length 0x00001795 (6037)
* Revision 0x01 **** 32-bit table (V1), no 64-bit math support
* Checksum 0xDE
* OEM ID "BOCHS "
* OEM Table ID "BXPC "
* OEM Revision 0x00000001 (1)
* Compiler ID "BXPC"
* Compiler Version 0x00000001 (1)
*/
DefinitionBlock ("", "DSDT", 1, "BOCHS ", "BXPC ", 0x00000001)
{
Scope (\)
{
OperationRegion (DBG, SystemIO, 0x0402, One)
Field (DBG, ByteAcc, NoLock, Preserve)
{
DBGB, 8
}
Method (DBUG, 1, NotSerialized)
{
ToHexString (Arg0, Local0)
ToBuffer (Local0, Local0)
Local1 = (SizeOf (Local0) - One)
Local2 = Zero
While ((Local2 < Local1))
{
DBGB = DerefOf (Local0 [Local2])
Local2++
}
DBGB = 0x0A
}
}
Scope (_SB)
{
Device (PCI0)
{
Name (_HID, EisaId ("PNP0A03") /* PCI Bus */) // _HID: Hardware ID
Name (_ADR, Zero) // _ADR: Address
Name (_UID, Zero) // _UID: Unique ID
}
}
Scope (_SB)
{
Device (HPET)
{
Name (_HID, EisaId ("PNP0103") /* HPET System Timer */) // _HID: Hardware ID
Name (_UID, Zero) // _UID: Unique ID
OperationRegion (HPTM, SystemMemory, 0xFED00000, 0x0400)
Field (HPTM, DWordAcc, Lock, Preserve)
{
VEND, 32,
PRD, 32
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
Local0 = VEND /* \_SB_.HPET.VEND */
Local1 = PRD /* \_SB_.HPET.PRD_ */
Local0 >>= 0x10
If (((Local0 == Zero) || (Local0 == 0xFFFF)))
{
Return (Zero)
}
If (((Local1 == Zero) || (Local1 > 0x05F5E100)))
{
Return (Zero)
}
Return (0x0F)
}
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
Memory32Fixed (ReadOnly,
0xFED00000, // Address Base
0x00000400, // Address Length
)
})
}
}
Scope (_SB.PCI0)
{
Device (ISA)
{
Name (_ADR, 0x00010000) // _ADR: Address
OperationRegion (P40C, PCI_Config, 0x60, 0x04)
}
}
Scope (_SB.PCI0.ISA)
{
Device (KBD)
{
Name (_HID, EisaId ("PNP0303") /* IBM Enhanced Keyboard (101/102-key, PS/2 Mouse) */) // _HID: Hardware ID
Name (_STA, 0x0F) // _STA: Status
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0x0060, // Range Minimum
0x0060, // Range Maximum
0x01, // Alignment
0x01, // Length
)
IO (Decode16,
0x0064, // Range Minimum
0x0064, // Range Maximum
0x01, // Alignment
0x01, // Length
)
IRQNoFlags ()
{1}
})
}
Device (MOU)
{
Name (_HID, EisaId ("PNP0F13") /* PS/2 Mouse */) // _HID: Hardware ID
Name (_STA, 0x0F) // _STA: Status
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IRQNoFlags ()
{12}
})
}
Device (FDC0)
{
Name (_HID, EisaId ("PNP0700")) // _HID: Hardware ID
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0x03F2, // Range Minimum
0x03F2, // Range Maximum
0x00, // Alignment
0x04, // Length
)
IO (Decode16,
0x03F7, // Range Minimum
0x03F7, // Range Maximum
0x00, // Alignment
0x01, // Length
)
IRQNoFlags ()
{6}
DMA (Compatibility, NotBusMaster, Transfer8, )
{2}
})
Device (FLPA)
{
Name (_ADR, Zero) // _ADR: Address
Name (_FDI, Package (0x10) // _FDI: Floppy Drive Information
{
Zero,
0x05,
0x4F,
0x30,
One,
0xAF,
0x02,
0x25,
0x02,
0x12,
0x1B,
0xFF,
0x6C,
0xF6,
0x0F,
0x08
})
}
Name (_FDE, Buffer (0x14) // _FDE: Floppy Disk Enumerate
{
/* 0000 */ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // ........
/* 0008 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // ........
/* 0010 */ 0x02, 0x00, 0x00, 0x00 // ....
})
}
Device (LPT1)
{
Name (_HID, EisaId ("PNP0400") /* Standard LPT Parallel Port */) // _HID: Hardware ID
Name (_UID, One) // _UID: Unique ID
Name (_STA, 0x0F) // _STA: Status
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0x0378, // Range Minimum
0x0378, // Range Maximum
0x08, // Alignment
0x08, // Length
)
IRQNoFlags ()
{7}
})
}
Device (COM1)
{
Name (_HID, EisaId ("PNP0501") /* 16550A-compatible COM Serial Port */) // _HID: Hardware ID
Name (_UID, One) // _UID: Unique ID
Name (_STA, 0x0F) // _STA: Status
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0x03F8, // Range Minimum
0x03F8, // Range Maximum
0x00, // Alignment
0x08, // Length
)
IRQNoFlags ()
{4}
})
}
Device (RTC)
{
Name (_HID, EisaId ("PNP0B00") /* AT Real-Time Clock */) // _HID: Hardware ID
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x01, // Alignment
0x08, // Length
)
IRQNoFlags ()
{8}
})
}
}
Scope (_SB.PCI0)
{
OperationRegion (PCST, SystemIO, 0xAE00, 0x08)
Field (PCST, DWordAcc, NoLock, WriteAsZeros)
{
PCIU, 32,
PCID, 32
}
OperationRegion (SEJ, SystemIO, 0xAE08, 0x04)
Field (SEJ, DWordAcc, NoLock, WriteAsZeros)
{
B0EJ, 32
}
OperationRegion (BNMR, SystemIO, 0xAE10, 0x08)
Field (BNMR, DWordAcc, NoLock, WriteAsZeros)
{
BNUM, 32,
PIDX, 32
}
Mutex (BLCK, 0x00)
Method (PCEJ, 2, NotSerialized)
{
Acquire (BLCK, 0xFFFF)
BNUM = Arg0
B0EJ = (One << Arg1)
Release (BLCK)
Return (Zero)
}
Method (AIDX, 2, NotSerialized)
{
Acquire (BLCK, 0xFFFF)
BNUM = Arg0
PIDX = (One << Arg1)
Local0 = PIDX /* \_SB_.PCI0.PIDX */
Release (BLCK)
Return (Local0)
}
Method (PDSM, 6, Serialized)
{
If ((Arg0 == ToUUID ("e5c937d0-3553-4d7a-9117-ea4d19c3434d") /* Device Labeling Interface */))
{
Local0 = AIDX (Arg4, Arg5)
If ((Arg2 == Zero))
{
If ((Arg1 == 0x02))
{
If (!((Local0 == Zero) | (Local0 == 0xFFFFFFFF)))
{
Return (Buffer (One)
{
0x81 // .
})
}
}
Return (Buffer (One)
{
0x00 // .
})
}
ElseIf ((Arg2 == 0x07))
{
Local1 = Package (0x02)
{
Zero,
""
}
Local1 [Zero] = Local0
Return (Local1)
}
}
}
}
Scope (_SB)
{
Scope (PCI0)
{
Method (_PRT, 0, NotSerialized) // _PRT: PCI Routing Table
{
Local0 = Package (0x80) {}
Local1 = Zero
While ((Local1 < 0x80))
{
Local2 = (Local1 >> 0x02)
Local3 = ((Local1 + Local2) & 0x03)
If ((Local3 == Zero))
{
Local4 = Package (0x04)
{
Zero,
Zero,
LNKD,
Zero
}
}
If ((Local3 == One))
{
If ((Local1 == 0x04))
{
Local4 = Package (0x04)
{
Zero,
Zero,
LNKS,
Zero
}
}
Else
{
Local4 = Package (0x04)
{
Zero,
Zero,
LNKA,
Zero
}
}
}
If ((Local3 == 0x02))
{
Local4 = Package (0x04)
{
Zero,
Zero,
LNKB,
Zero
}
}
If ((Local3 == 0x03))
{
Local4 = Package (0x04)
{
Zero,
Zero,
LNKC,
Zero
}
}
Local4 [Zero] = ((Local2 << 0x10) | 0xFFFF)
Local4 [One] = (Local1 & 0x03)
Local0 [Local1] = Local4
Local1++
}
Return (Local0)
}
}
Field (PCI0.ISA.P40C, ByteAcc, NoLock, Preserve)
{
PRQ0, 8,
PRQ1, 8,
PRQ2, 8,
PRQ3, 8
}
Method (IQST, 1, NotSerialized)
{
If ((0x80 & Arg0))
{
Return (0x09)
}
Return (0x0B)
}
Method (IQCR, 1, Serialized)
{
Name (PRR0, ResourceTemplate ()
{
Interrupt (ResourceConsumer, Level, ActiveHigh, Shared, ,, _Y00)
{
0x00000000,
}
})
CreateDWordField (PRR0, \_SB.IQCR._Y00._INT, PRRI) // _INT: Interrupts
If ((Arg0 < 0x80))
{
PRRI = Arg0
}
Return (PRR0) /* \_SB_.IQCR.PRR0 */
}
Device (LNKA)
{
Name (_HID, EisaId ("PNP0C0F") /* PCI Interrupt Link Device */) // _HID: Hardware ID
Name (_UID, Zero) // _UID: Unique ID
Name (_PRS, ResourceTemplate () // _PRS: Possible Resource Settings
{
Interrupt (ResourceConsumer, Level, ActiveHigh, Shared, ,, )
{
0x00000005,
0x0000000A,
0x0000000B,
}
})
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (IQST (PRQ0))
}
Method (_DIS, 0, NotSerialized) // _DIS: Disable Device
{
PRQ0 |= 0x80
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Return (IQCR (PRQ0))
}
Method (_SRS, 1, NotSerialized) // _SRS: Set Resource Settings
{
CreateDWordField (Arg0, 0x05, PRRI)
PRQ0 = PRRI /* \_SB_.LNKA._SRS.PRRI */
}
}
Device (LNKB)
{
Name (_HID, EisaId ("PNP0C0F") /* PCI Interrupt Link Device */) // _HID: Hardware ID
Name (_UID, One) // _UID: Unique ID
Name (_PRS, ResourceTemplate () // _PRS: Possible Resource Settings
{
Interrupt (ResourceConsumer, Level, ActiveHigh, Shared, ,, )
{
0x00000005,
0x0000000A,
0x0000000B,
}
})
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (IQST (PRQ1))
}
Method (_DIS, 0, NotSerialized) // _DIS: Disable Device
{
PRQ1 |= 0x80
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Return (IQCR (PRQ1))
}
Method (_SRS, 1, NotSerialized) // _SRS: Set Resource Settings
{
CreateDWordField (Arg0, 0x05, PRRI)
PRQ1 = PRRI /* \_SB_.LNKB._SRS.PRRI */
}
}
Device (LNKC)
{
Name (_HID, EisaId ("PNP0C0F") /* PCI Interrupt Link Device */) // _HID: Hardware ID
Name (_UID, 0x02) // _UID: Unique ID
Name (_PRS, ResourceTemplate () // _PRS: Possible Resource Settings
{
Interrupt (ResourceConsumer, Level, ActiveHigh, Shared, ,, )
{
0x00000005,
0x0000000A,
0x0000000B,
}
})
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (IQST (PRQ2))
}
Method (_DIS, 0, NotSerialized) // _DIS: Disable Device
{
PRQ2 |= 0x80
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Return (IQCR (PRQ2))
}
Method (_SRS, 1, NotSerialized) // _SRS: Set Resource Settings
{
CreateDWordField (Arg0, 0x05, PRRI)
PRQ2 = PRRI /* \_SB_.LNKC._SRS.PRRI */
}
}
Device (LNKD)
{
Name (_HID, EisaId ("PNP0C0F") /* PCI Interrupt Link Device */) // _HID: Hardware ID
Name (_UID, 0x03) // _UID: Unique ID
Name (_PRS, ResourceTemplate () // _PRS: Possible Resource Settings
{
Interrupt (ResourceConsumer, Level, ActiveHigh, Shared, ,, )
{
0x00000005,
0x0000000A,
0x0000000B,
}
})
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (IQST (PRQ3))
}
Method (_DIS, 0, NotSerialized) // _DIS: Disable Device
{
PRQ3 |= 0x80
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Return (IQCR (PRQ3))
}
Method (_SRS, 1, NotSerialized) // _SRS: Set Resource Settings
{
CreateDWordField (Arg0, 0x05, PRRI)
PRQ3 = PRRI /* \_SB_.LNKD._SRS.PRRI */
}
}
Device (LNKS)
{
Name (_HID, EisaId ("PNP0C0F") /* PCI Interrupt Link Device */) // _HID: Hardware ID
Name (_UID, 0x04) // _UID: Unique ID
Name (_PRS, ResourceTemplate () // _PRS: Possible Resource Settings
{
Interrupt (ResourceConsumer, Level, ActiveHigh, Shared, ,, )
{
0x00000009,
}
})
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0B)
}
Method (_DIS, 0, NotSerialized) // _DIS: Disable Device
{
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Return (_PRS) /* \_SB_.LNKS._PRS */
}
Method (_SRS, 1, NotSerialized) // _SRS: Set Resource Settings
{
}
}
}
Scope (_SB)
{
Device (\_SB.PCI0.PRES)
{
Name (_HID, EisaId ("PNP0A06") /* Generic Container Device */) // _HID: Hardware ID
Name (_UID, "CPU Hotplug resources") // _UID: Unique ID
Mutex (CPLK, 0x00)
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0xAF00, // Range Minimum
0xAF00, // Range Maximum
0x01, // Alignment
0x0C, // Length
)
})
OperationRegion (PRST, SystemIO, 0xAF00, 0x0C)
Field (PRST, ByteAcc, NoLock, WriteAsZeros)
{
Offset (0x04),
CPEN, 1,
CINS, 1,
CRMV, 1,
CEJ0, 1,
CEJF, 1,
Offset (0x05),
CCMD, 8
}
Field (PRST, DWordAcc, NoLock, Preserve)
{
CSEL, 32,
Offset (0x08),
CDAT, 32
}
Method (_INI, 0, Serialized) // _INI: Initialize
{
CSEL = Zero
}
}
Device (\_SB.CPUS)
{
Name (_HID, "ACPI0010" /* Processor Container Device */) // _HID: Hardware ID
Name (_CID, EisaId ("PNP0A05") /* Generic Container Device */) // _CID: Compatible ID
Method (CTFY, 2, NotSerialized)
{
If ((Arg0 == Zero))
{
Notify (C000, Arg1)
}
}
Method (CSTA, 1, Serialized)
{
Acquire (\_SB.PCI0.PRES.CPLK, 0xFFFF)
\_SB.PCI0.PRES.CSEL = Arg0
Local0 = Zero
If ((\_SB.PCI0.PRES.CPEN == One))
{
Local0 = 0x0F
}
Release (\_SB.PCI0.PRES.CPLK)
Return (Local0)
}
Method (CEJ0, 1, Serialized)
{
Acquire (\_SB.PCI0.PRES.CPLK, 0xFFFF)
\_SB.PCI0.PRES.CSEL = Arg0
\_SB.PCI0.PRES.CEJ0 = One
Release (\_SB.PCI0.PRES.CPLK)
}
Method (CSCN, 0, Serialized)
{
Acquire (\_SB.PCI0.PRES.CPLK, 0xFFFF)
Name (CNEW, Package (0xFF) {})
Local3 = Zero
Local4 = One
While ((Local4 == One))
{
Local4 = Zero
Local0 = One
Local1 = Zero
While (((Local0 == One) && (Local3 < One)))
{
Local0 = Zero
\_SB.PCI0.PRES.CSEL = Local3
\_SB.PCI0.PRES.CCMD = Zero
If ((\_SB.PCI0.PRES.CDAT < Local3))
{
Break
}
If ((Local1 == 0xFF))
{
Local4 = One
Break
}
Local3 = \_SB.PCI0.PRES.CDAT
If ((\_SB.PCI0.PRES.CINS == One))
{
CNEW [Local1] = Local3
Local1++
Local0 = One
}
ElseIf ((\_SB.PCI0.PRES.CRMV == One))
{
CTFY (Local3, 0x03)
\_SB.PCI0.PRES.CRMV = One
Local0 = One
}
Local3++
}
Local2 = Zero
While ((Local2 < Local1))
{
Local3 = DerefOf (CNEW [Local2])
CTFY (Local3, One)
Debug = Local3
\_SB.PCI0.PRES.CSEL = Local3
\_SB.PCI0.PRES.CINS = One
Local2++
}
}
Release (\_SB.PCI0.PRES.CPLK)
}
Method (COST, 4, Serialized)
{
Acquire (\_SB.PCI0.PRES.CPLK, 0xFFFF)
\_SB.PCI0.PRES.CSEL = Arg0
\_SB.PCI0.PRES.CCMD = One
\_SB.PCI0.PRES.CDAT = Arg1
\_SB.PCI0.PRES.CCMD = 0x02
\_SB.PCI0.PRES.CDAT = Arg2
Release (\_SB.PCI0.PRES.CPLK)
}
Processor (C000, 0x00, 0x00000000, 0x00)
{
Method (_STA, 0, Serialized) // _STA: Status
{
Return (CSTA (Zero))
}
Name (_MAT, Buffer (0x08) // _MAT: Multiple APIC Table Entry
{
0x00, 0x08, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00 // ........
})
Method (_OST, 3, Serialized) // _OST: OSPM Status Indication
{
COST (Zero, Arg0, Arg1, Arg2)
}
}
}
}
Method (\_GPE._E02, 0, NotSerialized) // _Exx: Edge-Triggered GPE, xx=0x00-0xFF
{
\_SB.CPUS.CSCN ()
}
Scope (_GPE)
{
Name (_HID, "ACPI0006" /* GPE Block Device */) // _HID: Hardware ID
Method (_E01, 0, NotSerialized) // _Exx: Edge-Triggered GPE, xx=0x00-0xFF
{
Acquire (\_SB.PCI0.BLCK, 0xFFFF)
\_SB.PCI0.PCNT ()
Release (\_SB.PCI0.BLCK)
}
}
Scope (\_SB.PCI0)
{
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode,
0x0000, // Granularity
0x0000, // Range Minimum
0x00FF, // Range Maximum
0x0000, // Translation Offset
0x0100, // Length
,, )
IO (Decode16,
0x0CF8, // Range Minimum
0x0CF8, // Range Maximum
0x01, // Alignment
0x08, // Length
)
WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
0x0000, // Granularity
0x0000, // Range Minimum
0x0CF7, // Range Maximum
0x0000, // Translation Offset
0x0CF8, // Length
,, , TypeStatic, DenseTranslation)
WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
0x0000, // Granularity
0x0D00, // Range Minimum
0xFFFF, // Range Maximum
0x0000, // Translation Offset
0xF300, // Length
,, , TypeStatic, DenseTranslation)
DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite,
0x00000000, // Granularity
0x000A0000, // Range Minimum
0x000BFFFF, // Range Maximum
0x00000000, // Translation Offset
0x00020000, // Length
,, , AddressRangeMemory, TypeStatic)
DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite,
0x00000000, // Granularity
0xC0000000, // Range Minimum
0xFEBFFFFF, // Range Maximum
0x00000000, // Translation Offset
0x3EC00000, // Length
,, , AddressRangeMemory, TypeStatic)
QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite,
0x0000000000000000, // Granularity
0x0000000140000000, // Range Minimum
0x00000001BFFFFFFF, // Range Maximum
0x0000000000000000, // Translation Offset
0x0000000080000000, // Length
,, , AddressRangeMemory, TypeStatic)
})
Device (GPE0)
{
Name (_HID, "PNP0A06" /* Generic Container Device */) // _HID: Hardware ID
Name (_UID, "GPE0 resources") // _UID: Unique ID
Name (_STA, 0x0B) // _STA: Status
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0xAFE0, // Range Minimum
0xAFE0, // Range Maximum
0x01, // Alignment
0x04, // Length
)
})
}
Device (PHPR)
{
Name (_HID, "PNP0A06" /* Generic Container Device */) // _HID: Hardware ID
Name (_UID, "PCI Hotplug resources") // _UID: Unique ID
Name (_STA, 0x0B) // _STA: Status
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0xAE00, // Range Minimum
0xAE00, // Range Maximum
0x01, // Alignment
0x18, // Length
)
})
}
}
Scope (\)
{
Name (_S3, Package (0x04) // _S3_: S3 System State
{
One,
One,
Zero,
Zero
})
Name (_S4, Package (0x04) // _S4_: S4 System State
{
0x02,
0x02,
Zero,
Zero
})
Name (_S5, Package (0x04) // _S5_: S5 System State
{
Zero,
Zero,
Zero,
Zero
})
}
Scope (\_SB.PCI0)
{
Device (FWCF)
{
Name (_HID, "QEMU0002") // _HID: Hardware ID
Name (_STA, 0x0B) // _STA: Status
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0x0510, // Range Minimum
0x0510, // Range Maximum
0x01, // Alignment
0x0C, // Length
)
})
}
}
Scope (\_SB)
{
Scope (PCI0)
{
Name (BSEL, Zero)
Device (S00)
{
Name (_ADR, Zero) // _ADR: Address
Name (ASUN, Zero)
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
}
}
Device (S10)
{
Name (_ADR, 0x00020000) // _ADR: Address
Name (ASUN, 0x02)
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
}
Method (_S1D, 0, NotSerialized) // _S1D: S1 Device State
{
Return (Zero)
}
Method (_S2D, 0, NotSerialized) // _S2D: S2 Device State
{
Return (Zero)
}
Method (_S3D, 0, NotSerialized) // _S3D: S3 Device State
{
Return (Zero)
}
}
Device (S18)
{
Name (_ADR, 0x00030000) // _ADR: Address
Name (ASUN, 0x03)
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
}
Name (_SUN, 0x03) // _SUN: Slot User Number
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
}
Device (S20)
{
Name (_ADR, 0x00040000) // _ADR: Address
Name (ASUN, 0x04)
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
}
Name (_SUN, 0x04) // _SUN: Slot User Number
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
}
Device (S28)
{
Name (_ADR, 0x00050000) // _ADR: Address
Name (ASUN, 0x05)
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
}
Name (_SUN, 0x05) // _SUN: Slot User Number
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
}
Device (S30)
{
Name (_ADR, 0x00060000) // _ADR: Address
Name (ASUN, 0x06)
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
}
Name (_SUN, 0x06) // _SUN: Slot User Number
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
}
Device (S38)
{
Name (_ADR, 0x00070000) // _ADR: Address
Name (ASUN, 0x07)
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
}
Name (_SUN, 0x07) // _SUN: Slot User Number
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
}
Device (S40)
{
Name (_SUN, 0x08) // _SUN: Slot User Number
Name (_ADR, 0x00080000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (S48)
{
Name (_SUN, 0x09) // _SUN: Slot User Number
Name (_ADR, 0x00090000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (S50)
{
Name (_SUN, 0x0A) // _SUN: Slot User Number
Name (_ADR, 0x000A0000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (S58)
{
Name (_SUN, 0x0B) // _SUN: Slot User Number
Name (_ADR, 0x000B0000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (S60)
{
Name (_SUN, 0x0C) // _SUN: Slot User Number
Name (_ADR, 0x000C0000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (S68)
{
Name (_SUN, 0x0D) // _SUN: Slot User Number
Name (_ADR, 0x000D0000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (S70)
{
Name (_SUN, 0x0E) // _SUN: Slot User Number
Name (_ADR, 0x000E0000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (S78)
{
Name (_SUN, 0x0F) // _SUN: Slot User Number
Name (_ADR, 0x000F0000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (S80)
{
Name (_SUN, 0x10) // _SUN: Slot User Number
Name (_ADR, 0x00100000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (S88)
{
Name (_SUN, 0x11) // _SUN: Slot User Number
Name (_ADR, 0x00110000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (S90)
{
Name (_SUN, 0x12) // _SUN: Slot User Number
Name (_ADR, 0x00120000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (S98)
{
Name (_SUN, 0x13) // _SUN: Slot User Number
Name (_ADR, 0x00130000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (SA0)
{
Name (_SUN, 0x14) // _SUN: Slot User Number
Name (_ADR, 0x00140000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (SA8)
{
Name (_SUN, 0x15) // _SUN: Slot User Number
Name (_ADR, 0x00150000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (SB0)
{
Name (_SUN, 0x16) // _SUN: Slot User Number
Name (_ADR, 0x00160000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (SB8)
{
Name (_SUN, 0x17) // _SUN: Slot User Number
Name (_ADR, 0x00170000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (SC0)
{
Name (_SUN, 0x18) // _SUN: Slot User Number
Name (_ADR, 0x00180000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (SC8)
{
Name (_SUN, 0x19) // _SUN: Slot User Number
Name (_ADR, 0x00190000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (SD0)
{
Name (_SUN, 0x1A) // _SUN: Slot User Number
Name (_ADR, 0x001A0000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (SD8)
{
Name (_SUN, 0x1B) // _SUN: Slot User Number
Name (_ADR, 0x001B0000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (SE0)
{
Name (_SUN, 0x1C) // _SUN: Slot User Number
Name (_ADR, 0x001C0000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (SE8)
{
Name (_SUN, 0x1D) // _SUN: Slot User Number
Name (_ADR, 0x001D0000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (SF0)
{
Name (_SUN, 0x1E) // _SUN: Slot User Number
Name (_ADR, 0x001E0000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Device (SF8)
{
Name (_SUN, 0x1F) // _SUN: Slot User Number
Name (_ADR, 0x001F0000) // _ADR: Address
Method (_EJ0, 1, NotSerialized) // _EJx: Eject Device, x=0-9
{
PCEJ (BSEL, _SUN)
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
}
}
Method (DVNT, 2, NotSerialized)
{
If ((Arg0 & 0x08))
{
Notify (S18, Arg1)
}
If ((Arg0 & 0x10))
{
Notify (S20, Arg1)
}
If ((Arg0 & 0x20))
{
Notify (S28, Arg1)
}
If ((Arg0 & 0x40))
{
Notify (S30, Arg1)
}
If ((Arg0 & 0x80))
{
Notify (S38, Arg1)
}
If ((Arg0 & 0x0100))
{
Notify (S40, Arg1)
}
If ((Arg0 & 0x0200))
{
Notify (S48, Arg1)
}
If ((Arg0 & 0x0400))
{
Notify (S50, Arg1)
}
If ((Arg0 & 0x0800))
{
Notify (S58, Arg1)
}
If ((Arg0 & 0x1000))
{
Notify (S60, Arg1)
}
If ((Arg0 & 0x2000))
{
Notify (S68, Arg1)
}
If ((Arg0 & 0x4000))
{
Notify (S70, Arg1)
}
If ((Arg0 & 0x8000))
{
Notify (S78, Arg1)
}
If ((Arg0 & 0x00010000))
{
Notify (S80, Arg1)
}
If ((Arg0 & 0x00020000))
{
Notify (S88, Arg1)
}
If ((Arg0 & 0x00040000))
{
Notify (S90, Arg1)
}
If ((Arg0 & 0x00080000))
{
Notify (S98, Arg1)
}
If ((Arg0 & 0x00100000))
{
Notify (SA0, Arg1)
}
If ((Arg0 & 0x00200000))
{
Notify (SA8, Arg1)
}
If ((Arg0 & 0x00400000))
{
Notify (SB0, Arg1)
}
If ((Arg0 & 0x00800000))
{
Notify (SB8, Arg1)
}
If ((Arg0 & 0x01000000))
{
Notify (SC0, Arg1)
}
If ((Arg0 & 0x02000000))
{
Notify (SC8, Arg1)
}
If ((Arg0 & 0x04000000))
{
Notify (SD0, Arg1)
}
If ((Arg0 & 0x08000000))
{
Notify (SD8, Arg1)
}
If ((Arg0 & 0x10000000))
{
Notify (SE0, Arg1)
}
If ((Arg0 & 0x20000000))
{
Notify (SE8, Arg1)
}
If ((Arg0 & 0x40000000))
{
Notify (SF0, Arg1)
}
If ((Arg0 & 0x80000000))
{
Notify (SF8, Arg1)
}
}
Method (PCNT, 0, NotSerialized)
{
BNUM = Zero
DVNT (PCIU, One)
DVNT (PCID, 0x03)
}
}
}
}
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: input: atmel,maxtouch: add linux,keycodes
From: Linus Walleij @ 2023-03-06 14:19 UTC (permalink / raw)
To: André Apitzsch
Cc: Nick Dyer, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, linux-input,
devicetree, linux-arm-kernel, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <20230227205035.18551-1-git@apitzsch.eu>
On Mon, Feb 27, 2023 at 9:50 PM André Apitzsch <git@apitzsch.eu> wrote:
> In some configurations the touch controller can support the touch keys.
> Document the linux,keycodes property that enables those keys and
> specifies the keycodes that should be used to report the key events.
>
> Signed-off-by: André Apitzsch <git@apitzsch.eu>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Andy Shevchenko @ 2023-03-06 13:07 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Daniel Kaehn, Hans de Goede, robh+dt, krzysztof.kozlowski+dt,
jikos, bartosz.golaszewski, dmitry.torokhov, devicetree,
linux-input, ethan.twardy
In-Reply-To: <b8423b0b-4f63-d598-6c8b-7c7e73549032@redhat.com>
On Mon, Mar 06, 2023 at 01:36:51PM +0100, Benjamin Tissoires wrote:
> On Mon, Mar 6, 2023 at 11:49 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > On Thu, Mar 02, 2023 at 06:06:06PM +0100, Benjamin Tissoires wrote:
> > > On Mar 01 2023, Andy Shevchenko wrote:
> > > > On Tue, Feb 28, 2023 at 01:05:54PM -0600, Daniel Kaehn wrote:
...
[1]: https://stackoverflow.com/a/60855157/2511795
> > > Thanks Andy for your help here, and thanks for that link.
> > >
> > > I am trying to test Danny's patch as I want to use it for my HID CI,
> > > being an owner of a CP2112 device myself.
> > >
> > > The current setup is using out of the tree patches [2] which are
> > > implementing a platform i2c-hid support and some manual addition of a
> > > I2C-HID device on top of it. This works fine but gets busted every now
> > > and then when the tree sees a change that conflicts with these patches.
> > >
> > > So with Danny's series, I thought I could have an SSDT override to
> > > declare that very same device instead of patching my kernel before
> > > testing it.
> > >
> > > Of course, it gets tricky because I need to run that under qemu.
> > >
> > > I am currently stuck at the "sharing the firmware_node from usb with
> > > HID" step and I'd like to know if you could help me.
> > >
> > > On my laptop, if I plug the CP2112 (without using a USB hub), I can get:
> > >
> > > $> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
> > > lrwxrwxrwx. 1 root root 0 Mar 2 17:02 /sys/bus/hid/devices/0003:10C4:EA90.0079 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-9/2-9:1.0/0003:10C4:EA90.0079
> > > $> ls -l /sys/bus/usb/devices/2-9*/firmware_node
> > > lrwxrwxrwx. 1 root root 0 Mar 2 17:03 /sys/bus/usb/devices/2-9:1.0/firmware_node -> ../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:25
> > > lrwxrwxrwx. 1 root root 0 Mar 2 17:02 /sys/bus/usb/devices/2-9/firmware_node -> ../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:25
> > >
> > > So AFAIU the USB device is properly assigned a firmware node. My dsdt
> > > also shows the "Device (RHUB)" and I guess everything is fine.
> >
> > Yes, so far so good.
> >
> > > However, playing with qemu is not so easy.
> > >
> > > I am running qemu with the following arguments (well, almost because I
> > > have a wrapper script on top of it and I also run the compiled kernel
> > > from the current tree):
> > >
> > > #> qemu-system-x86_64 -bios /usr/share/edk2/ovmf/OVMF_CODE.fd \
> > > -netdev user,id=hostnet0 \
> > > -device virtio-net-pci,netdev=hostnet0 \
> > > -m 4G \
> > > -enable-kvm \
> > > -cpu host \
> > > -device qemu-xhci -usb \
> > > -device 'usb-host,vendorid=0x10c4,productid=0xea90' \
> > > -cdrom ~/Downloads/Fedora-Workstation-Live-x86_64-37-1.7.iso
> >
> > Side question, where can I get those blobs from (EDKII and Fedora Live CD)?
> > I'm using Debian unstable.
>
> You can install the ovmf package in debian[3], which should have a
> similar file.
> For the Fedora livecd -> https://getfedora.org/fr/workstation/download/
> but any other distribution with a recent enough kernel should show the
> same.
Thank you!
> > > And this is what I get:
> > >
> > > #> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
> > > lrwxrwxrwx 1 root root 0 Mar 2 16:10 /sys/bus/hid/devices/0003:10C4:EA90.0001 -> ../../../devices/pci0000:00/0000:00:06.0/usb2/2-1/2-1:1.0/0003:10C4:EA90.0001
> > >
> > > #> ls -l /sys/bus/usb/devices/2-1*/firmware_node
> > > ls: cannot access '/sys/bus/usb/devices/2-1*/firmware_node': No such file or directory
> > >
> > > Looking at the DSDT, I do not see any reference to the USB hub, so I
> > > wonder if the firmware_node needs to be populated first in the DSDT.
> >
> > So, where QEMU takes DSDT (ACPI tables in general) from? Can you patch that?
> > I believe that's the problem in qemu.
>
> That's a good question and it's one I am not sure I have the answer to.
> I would have assumed that the DSDT was in the OVMF firmware, but given
> that we can arbitrarily add command line arguments, I believe it
> probably just provides a baseline and then we are screwed. The OVMF bios
> is compiled only once, so I doubt there is any mechanism to
> enable/disable a component in the DSDT, or make it dynamically
> generated.
We have two ways of filling missing parts:
1) update the original source of DSDT (firmware or bootloader,
whichever provides that);
2) adding an overlay.
The 2) works _if and only if_ there is *no* existing object in the tables.
In such cases, you can simply provide a *full* hierarchy. See an example of
PCI devices in the kernel documentation on how to do that. I believe something
similar can be done for USB.
> > > Also note that if I plug the CP2112 over a docking station, I lose the
> > > firmware_node sysfs entries on the host too.
> >
> > This seems like a lack of firmware node propagating in the USB hub code in
> > the Linux kernel.
>
> That would make a lot of sense.
>
> FWIW, in the VM I see a firmware node on the pci controller itself:
> #> ls -l /sys/devices/pci0000\:00/0000\:00\:06.0/firmware_node
> lrwxrwxrwx 1 root root 0 Mar 6 12:24 /sys/devices/pci0000:00/0000:00:06.0/firmware_node -> ../../LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07
>
> And one the host, through a USB hub:
>
> #> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
> lrwxrwxrwx. 1 root root 0 Mar 6 13:26 /sys/bus/hid/devices/0003:10C4:EA90.007C -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-8/2-8.2/2-8.2.4/2-8.2.4:1.0/0003:10C4:EA90.007C
> #> ls -l /sys/bus/usb/devices/2-8*/firmware_node
> lrwxrwxrwx. 1 root root 0 Mar 2 16:53 /sys/bus/usb/devices/2-8:1.0/firmware_node -> ../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:1e
> lrwxrwxrwx. 1 root root 0 Mar 2 16:53 /sys/bus/usb/devices/2-8/firmware_node -> ../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:1e
>
> Note that the firmware node propagation stopped at 2-8, and 2.8.2 is not
> having a firmware node.
It would be nice if you can run `grep -H 15 /sys/bus/acpi/devices/*/status`,
filter out unneeded ones, and for the rest also print their paths:
`cat filtered_list_of_acpi_devs | while read p; do grep -H . $p/path; done`
With this we will see what devices are actually present and up and running
in the system and what their paths in the ACPI namespace.
> > > Do you think it would be achievable to emulate that over qemu and use a
> > > mainline kernel without patches?
> >
> > As long as qemu provides correct DSDT it should work I assume.
>
> Just to be sure I understand, for this to work, we need the DSDT to
> export a "Device(RHUB)"?
Not sure I understand the term "export" here. We need a description
of the (to describe) missing parts.
> Or if we fix the USB fw_node propagation, could we just overwrite
> "\_SB_.PCI0.S30_"? "\_SB_.PCI0.S30_" is the name the ACPI is giving to
> the USB port in my VM case AFAIU.
I have no idea what is the S30 node.
[2] https://gitlab.freedesktop.org/bentiss/gitlab-kernel-ci/-/tree/master/VM
[3] https://packages.debian.org/buster/all/ovmf/filelist
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Benjamin Tissoires @ 2023-03-06 12:36 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Daniel Kaehn, Hans de Goede, robh+dt, krzysztof.kozlowski+dt,
jikos, bartosz.golaszewski, dmitry.torokhov, devicetree,
linux-input, ethan.twardy
In-Reply-To: <ZAXFNRuALYpXgL6F@smile.fi.intel.com>
On Mon, Mar 6, 2023 at 11:49 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
> On Thu, Mar 02, 2023 at 06:06:06PM +0100, Benjamin Tissoires wrote:
> > On Mar 01 2023, Andy Shevchenko wrote:
> > > On Tue, Feb 28, 2023 at 01:05:54PM -0600, Daniel Kaehn wrote:
>
> ...
>
> > > [1]: https://stackoverflow.com/a/60855157/2511795
> >
> > Thanks Andy for your help here, and thanks for that link.
> >
> > I am trying to test Danny's patch as I want to use it for my HID CI,
> > being an owner of a CP2112 device myself.
> >
> > The current setup is using out of the tree patches [2] which are
> > implementing a platform i2c-hid support and some manual addition of a
> > I2C-HID device on top of it. This works fine but gets busted every now
> > and then when the tree sees a change that conflicts with these patches.
> >
> > So with Danny's series, I thought I could have an SSDT override to
> > declare that very same device instead of patching my kernel before
> > testing it.
> >
> > Of course, it gets tricky because I need to run that under qemu.
> >
> > I am currently stuck at the "sharing the firmware_node from usb with
> > HID" step and I'd like to know if you could help me.
> >
> > On my laptop, if I plug the CP2112 (without using a USB hub), I can get:
> >
> > $> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
> > lrwxrwxrwx. 1 root root 0 Mar 2 17:02 /sys/bus/hid/devices/0003:10C4:EA90.0079 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-9/2-9:1.0/0003:10C4:EA90.0079
> > $> ls -l /sys/bus/usb/devices/2-9*/firmware_node
> > lrwxrwxrwx. 1 root root 0 Mar 2 17:03 /sys/bus/usb/devices/2-9:1.0/firmware_node -> ../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:25
> > lrwxrwxrwx. 1 root root 0 Mar 2 17:02 /sys/bus/usb/devices/2-9/firmware_node -> ../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:25
> >
> > So AFAIU the USB device is properly assigned a firmware node. My dsdt
> > also shows the "Device (RHUB)" and I guess everything is fine.
>
> Yes, so far so good.
>
> > However, playing with qemu is not so easy.
> >
> > I am running qemu with the following arguments (well, almost because I
> > have a wrapper script on top of it and I also run the compiled kernel
> > from the current tree):
> >
> > #> qemu-system-x86_64 -bios /usr/share/edk2/ovmf/OVMF_CODE.fd \
> > -netdev user,id=hostnet0 \
> > -device virtio-net-pci,netdev=hostnet0 \
> > -m 4G \
> > -enable-kvm \
> > -cpu host \
> > -device qemu-xhci -usb \
> > -device 'usb-host,vendorid=0x10c4,productid=0xea90' \
> > -cdrom ~/Downloads/Fedora-Workstation-Live-x86_64-37-1.7.iso
>
> Side question, where can I get those blobs from (EDKII and Fedora Live CD)?
> I'm using Debian unstable.
You can install the ovmf package in debian[3], which should have a
similar file.
For the Fedora livecd -> https://getfedora.org/fr/workstation/download/
but any other distribution with a recent enough kernel should show the
same.
>
>
> > And this is what I get:
> >
> > #> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
> > lrwxrwxrwx 1 root root 0 Mar 2 16:10 /sys/bus/hid/devices/0003:10C4:EA90.0001 -> ../../../devices/pci0000:00/0000:00:06.0/usb2/2-1/2-1:1.0/0003:10C4:EA90.0001
> >
> > #> ls -l /sys/bus/usb/devices/2-1*/firmware_node
> > ls: cannot access '/sys/bus/usb/devices/2-1*/firmware_node': No such file or directory
> >
> > Looking at the DSDT, I do not see any reference to the USB hub, so I
> > wonder if the firmware_node needs to be populated first in the DSDT.
>
> So, where QEMU takes DSDT (ACPI tables in general) from? Can you patch that?
> I believe that's the problem in qemu.
That's a good question and it's one I am not sure I have the answer to.
I would have assumed that the DSDT was in the OVMF firmware, but given
that we can arbitrarily add command line arguments, I believe it
probably just provides a baseline and then we are screwed. The OVMF bios
is compiled only once, so I doubt there is any mechanism to
enable/disable a component in the DSDT, or make it dynamically
generated.
>
> > Also note that if I plug the CP2112 over a docking station, I lose the
> > firmware_node sysfs entries on the host too.
>
> This seems like a lack of firmware node propagating in the USB hub code in
> the Linux kernel.
That would make a lot of sense.
FWIW, in the VM I see a firmware node on the pci controller itself:
#> ls -l /sys/devices/pci0000\:00/0000\:00\:06.0/firmware_node
lrwxrwxrwx 1 root root 0 Mar 6 12:24 /sys/devices/pci0000:00/0000:00:06.0/firmware_node -> ../../LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07
And one the host, through a USB hub:
#> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
lrwxrwxrwx. 1 root root 0 Mar 6 13:26 /sys/bus/hid/devices/0003:10C4:EA90.007C -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-8/2-8.2/2-8.2.4/2-8.2.4:1.0/0003:10C4:EA90.007C
#> ls -l /sys/bus/usb/devices/2-8*/firmware_node
lrwxrwxrwx. 1 root root 0 Mar 2 16:53 /sys/bus/usb/devices/2-8:1.0/firmware_node -> ../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:1e
lrwxrwxrwx. 1 root root 0 Mar 2 16:53 /sys/bus/usb/devices/2-8/firmware_node -> ../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:1e
Note that the firmware node propagation stopped at 2-8, and 2.8.2 is not
having a firmware node.
>
> > Do you think it would be achievable to emulate that over qemu and use a
> > mainline kernel without patches?
>
> As long as qemu provides correct DSDT it should work I assume.
Just to be sure I understand, for this to work, we need the DSDT to
export a "Device(RHUB)"?
Or if we fix the USB fw_node propagation, could we just overwrite
"\_SB_.PCI0.S30_"? "\_SB_.PCI0.S30_" is the name the ACPI is giving to
the USB port in my VM case AFAIU.
Cheers,
Benjamin
>
> > [2] https://gitlab.freedesktop.org/bentiss/gitlab-kernel-ci/-/tree/master/VM
[3] https://packages.debian.org/buster/all/ovmf/filelist
^ permalink raw reply
* Re: [PATCH] Input: i8042 - Add quirk for Fujitsu Lifebook A574/H
From: Hans de Goede @ 2023-03-06 11:00 UTC (permalink / raw)
To: Jonathan Denose, LKML
Cc: Jonathan Denose, Dmitry Torokhov, Huacai Chen,
Mattijs Korpershoek, Takashi Iwai, Werner Sembach, Wolfram Sang,
linux-input
In-Reply-To: <20230303152623.45859-1-jdenose@google.com>
Hi,
On 3/3/23 16:26, Jonathan Denose wrote:
> Fujitsu Lifebook A574/H requires the nomux option to properly
> probe the touchpad, especially when waking from sleep.
>
> Signed-off-by: Jonathan Denose <jdenose@google.com>
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
> ---
>
> drivers/input/serio/i8042-acpipnpio.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/input/serio/i8042-acpipnpio.h b/drivers/input/serio/i8042-acpipnpio.h
> index efc61736099b..fe7ffe30997c 100644
> --- a/drivers/input/serio/i8042-acpipnpio.h
> +++ b/drivers/input/serio/i8042-acpipnpio.h
> @@ -610,6 +610,14 @@ static const struct dmi_system_id i8042_dmi_quirk_table[] __initconst = {
> },
> .driver_data = (void *)(SERIO_QUIRK_NOMUX)
> },
> + {
> + /* Fujitsu Lifebook A574/H */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "FMVA0501PZ"),
> + },
> + .driver_data = (void *)(SERIO_QUIRK_NOMUX)
> + },
> {
> /* Gigabyte M912 */
> .matches = {
^ permalink raw reply
* Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
From: Andy Shevchenko @ 2023-03-06 10:49 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Daniel Kaehn, Hans de Goede, robh+dt, krzysztof.kozlowski+dt,
jikos, bartosz.golaszewski, dmitry.torokhov, devicetree,
linux-input, ethan.twardy
In-Reply-To: <20230302170554.q3426ii255735rzw@mail.corp.redhat.com>
On Thu, Mar 02, 2023 at 06:06:06PM +0100, Benjamin Tissoires wrote:
> On Mar 01 2023, Andy Shevchenko wrote:
> > On Tue, Feb 28, 2023 at 01:05:54PM -0600, Daniel Kaehn wrote:
...
> > [1]: https://stackoverflow.com/a/60855157/2511795
>
> Thanks Andy for your help here, and thanks for that link.
>
> I am trying to test Danny's patch as I want to use it for my HID CI,
> being an owner of a CP2112 device myself.
>
> The current setup is using out of the tree patches [2] which are
> implementing a platform i2c-hid support and some manual addition of a
> I2C-HID device on top of it. This works fine but gets busted every now
> and then when the tree sees a change that conflicts with these patches.
>
> So with Danny's series, I thought I could have an SSDT override to
> declare that very same device instead of patching my kernel before
> testing it.
>
> Of course, it gets tricky because I need to run that under qemu.
>
> I am currently stuck at the "sharing the firmware_node from usb with
> HID" step and I'd like to know if you could help me.
>
> On my laptop, if I plug the CP2112 (without using a USB hub), I can get:
>
> $> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
> lrwxrwxrwx. 1 root root 0 Mar 2 17:02 /sys/bus/hid/devices/0003:10C4:EA90.0079 -> ../../../devices/pci0000:00/0000:00:14.0/usb2/2-9/2-9:1.0/0003:10C4:EA90.0079
> $> ls -l /sys/bus/usb/devices/2-9*/firmware_node
> lrwxrwxrwx. 1 root root 0 Mar 2 17:03 /sys/bus/usb/devices/2-9:1.0/firmware_node -> ../../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:25
> lrwxrwxrwx. 1 root root 0 Mar 2 17:02 /sys/bus/usb/devices/2-9/firmware_node -> ../../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:15/device:16/device:25
>
> So AFAIU the USB device is properly assigned a firmware node. My dsdt
> also shows the "Device (RHUB)" and I guess everything is fine.
Yes, so far so good.
> However, playing with qemu is not so easy.
>
> I am running qemu with the following arguments (well, almost because I
> have a wrapper script on top of it and I also run the compiled kernel
> from the current tree):
>
> #> qemu-system-x86_64 -bios /usr/share/edk2/ovmf/OVMF_CODE.fd \
> -netdev user,id=hostnet0 \
> -device virtio-net-pci,netdev=hostnet0 \
> -m 4G \
> -enable-kvm \
> -cpu host \
> -device qemu-xhci -usb \
> -device 'usb-host,vendorid=0x10c4,productid=0xea90' \
> -cdrom ~/Downloads/Fedora-Workstation-Live-x86_64-37-1.7.iso
Side question, where can I get those blobs from (EDKII and Fedora Live CD)?
I'm using Debian unstable.
> And this is what I get:
>
> #> ls -l /sys/bus/hid/devices/0003:10C4:EA90.*
> lrwxrwxrwx 1 root root 0 Mar 2 16:10 /sys/bus/hid/devices/0003:10C4:EA90.0001 -> ../../../devices/pci0000:00/0000:00:06.0/usb2/2-1/2-1:1.0/0003:10C4:EA90.0001
>
> #> ls -l /sys/bus/usb/devices/2-1*/firmware_node
> ls: cannot access '/sys/bus/usb/devices/2-1*/firmware_node': No such file or directory
>
> Looking at the DSDT, I do not see any reference to the USB hub, so I
> wonder if the firmware_node needs to be populated first in the DSDT.
So, where QEMU takes DSDT (ACPI tables in general) from? Can you patch that?
I believe that's the problem in qemu.
> Also note that if I plug the CP2112 over a docking station, I lose the
> firmware_node sysfs entries on the host too.
This seems like a lack of firmware node propagating in the USB hub code in
the Linux kernel.
> Do you think it would be achievable to emulate that over qemu and use a
> mainline kernel without patches?
As long as qemu provides correct DSDT it should work I assume.
> [2] https://gitlab.freedesktop.org/bentiss/gitlab-kernel-ci/-/tree/master/VM
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Technický audit podlah
From: Lukáš Horváth @ 2023-03-06 8:41 UTC (permalink / raw)
To: linux-input
Dobré ráno,
uvažujete o bezespárové podlaze pro výrobní provoz?
Jako světový lídr ve výrobě a pokládce podlah řešíme problémy vyplývající z vlivu chemických sloučenin, otěru, nárazů, vlhkosti nebo náhlých změn teplot - naše podlahové systémy jsou přizpůsobeny nejtěžším podmínkám prostředí.
Garantujeme vám řešení, která jsou šetrná k životnímu prostředí, odolná a snadno se čistí, hygienická, protiskluzová a bezpečná pro zaměstnance.
Poskytujeme krátkou dobu instalace a nepřetržitý provoz i o víkendech a svátcích, čímž eliminujeme riziko prostojů.
Mohu Vám zdarma nabídnout technický audit podlah s komplexním rozborem podkladu.
Můžeme pro vás mluvit o řešeních?
Lukáš Horváth
^ permalink raw reply
* Re: [PATCH v2 2/2] Input: hideep - Optionally reset controller work mode to native HiDeep protocol
From: Hans de Goede @ 2023-03-05 15:04 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dmitry Torokhov; +Cc: devicetree, linux-input
In-Reply-To: <42ac04f2-e7dc-a5a8-750e-243aa82c35db@kernel.org>
Hi,
On 3/5/23 14:34, Krzysztof Kozlowski wrote:
> On 03/03/2023 23:21, Hans de Goede wrote:
>> The HiDeep IST940E touchscreen controller used on the Lenovo Yoga Book X90F
>> convertible comes up in HID mode by default.
>>
>> This works well on the X91F Windows model where the touchscreen is
>> correctly described in ACPI and ACPI takes care of controlling
>> the reset GPIO and regulators.
>>
>> But the X90F ships with Android and the ACPI tables on this model don't
>> describe the touchscreen. Instead this is hardcoded in the vendor kernel.
>>
>> The vendor kernel uses the touchscreen in native HiDeep 20 (2.0?) protocol
>> mode and switches the controller to this mode by writing 0 to reg 0x081e.
>>
>> Adjusting the i2c-hid code to deal with the reset-gpio and regulators on
>> this non devicetree (but rather broken ACPI) convertible is somewhat tricky
>> and the native protocol reports ABS_MT_PRESSURE and ABS_MT_TOUCH_MAJOR
>> which are not reported in HID mode, so it is preferable to use the native
>> mode.
>>
>> Add support to the hideep driver to reset the work-mode to the native
>> HiDeep protocol to allow using it on the Lenovo Yoga Book X90F.
>> This is guarded behind a new "hideep,reset-work-mode" boolean property,
>> to avoid changing behavior on other devices.
>>
>> For the record: I did test using the i2c-hid driver with some quick hacks
>> and it does work. The I2C-HID descriptor is available from address 0x0020,
>> just like on the X91F Windows model.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC. It might happen, that command when run on an older
> kernel, gives you outdated entries. Therefore please be sure you base
> your patches on recent Linux kernel.
>
>> ---
>> .../bindings/input/touchscreen/hideep.txt | 1 +
>> drivers/input/touchscreen/hideep.c | 16 ++++++++++++++++
>> 2 files changed, 17 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
>> index a47c36190b01..68bb9f8dcc30 100644
>> --- a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
>> +++ b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
>> @@ -17,6 +17,7 @@ Optional properties:
>> - linux,keycodes : Specifies an array of numeric keycode values to
>> be used for reporting button presses. The array can
>> contain up to 3 entries.
>> +- hideep,reset-work-mode: bool, reset touch report format to the native HiDeep protocol
>
> Bindings must be a separate patch.
>
> Also, would be nice to convert first the TXT to DT schema (YAML).
>
> "-mode" suggests it's some enum, not bool. Otherwise what exactly it is
> choosing (which mode)?
As it says it is resetting the mode to the native HiDeep protocol,
we have no docs on the controller, so I have no idea what other
values may be written to 0x081e other then 0 and what modes those
values will enable.
Anyways I just realized I should have not included this at all,
since atm this new property is only used on X86/ACPI platforms
(through platform code setting a device-property), so it is not
used on devicetree platforms at all.
And Rob has repeatedly requested to not add properties not
actually used in devicetree files (1) to the bindings.
So I'll just drop the bindings in the next version of this
patch-set.
Regards,
Hans
1) Like these x86 kinda kernel internal (it is also the kernel
setting the property) properties to devicetree bindings.
^ permalink raw reply
* Re: [PATCH v2 2/2] Input: hideep - Optionally reset controller work mode to native HiDeep protocol
From: Krzysztof Kozlowski @ 2023-03-05 13:34 UTC (permalink / raw)
To: Hans de Goede, Dmitry Torokhov; +Cc: devicetree, linux-input
In-Reply-To: <20230303222113.285546-3-hdegoede@redhat.com>
On 03/03/2023 23:21, Hans de Goede wrote:
> The HiDeep IST940E touchscreen controller used on the Lenovo Yoga Book X90F
> convertible comes up in HID mode by default.
>
> This works well on the X91F Windows model where the touchscreen is
> correctly described in ACPI and ACPI takes care of controlling
> the reset GPIO and regulators.
>
> But the X90F ships with Android and the ACPI tables on this model don't
> describe the touchscreen. Instead this is hardcoded in the vendor kernel.
>
> The vendor kernel uses the touchscreen in native HiDeep 20 (2.0?) protocol
> mode and switches the controller to this mode by writing 0 to reg 0x081e.
>
> Adjusting the i2c-hid code to deal with the reset-gpio and regulators on
> this non devicetree (but rather broken ACPI) convertible is somewhat tricky
> and the native protocol reports ABS_MT_PRESSURE and ABS_MT_TOUCH_MAJOR
> which are not reported in HID mode, so it is preferable to use the native
> mode.
>
> Add support to the hideep driver to reset the work-mode to the native
> HiDeep protocol to allow using it on the Lenovo Yoga Book X90F.
> This is guarded behind a new "hideep,reset-work-mode" boolean property,
> to avoid changing behavior on other devices.
>
> For the record: I did test using the i2c-hid driver with some quick hacks
> and it does work. The I2C-HID descriptor is available from address 0x0020,
> just like on the X91F Windows model.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.
> ---
> .../bindings/input/touchscreen/hideep.txt | 1 +
> drivers/input/touchscreen/hideep.c | 16 ++++++++++++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
> index a47c36190b01..68bb9f8dcc30 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
> @@ -17,6 +17,7 @@ Optional properties:
> - linux,keycodes : Specifies an array of numeric keycode values to
> be used for reporting button presses. The array can
> contain up to 3 entries.
> +- hideep,reset-work-mode: bool, reset touch report format to the native HiDeep protocol
Bindings must be a separate patch.
Also, would be nice to convert first the TXT to DT schema (YAML).
"-mode" suggests it's some enum, not bool. Otherwise what exactly it is
choosing (which mode)?
Best regards,
Krzysztof
^ permalink raw reply
* Re: "proximity" attribute for input devices
From: Sebastian Reichel @ 2023-03-04 1:09 UTC (permalink / raw)
To: Jason Gerecke
Cc: Limonciello, Mario, linux-input@vger.kernel.org, Bastien Nocera,
ping.cheng@wacom.com, jason.gerecke@wacom.com, linux-pm
In-Reply-To: <CANRwn3Tb1JgLpCiYFZBO1+PDHWLT-yxEPQ0TQ19xGDWZR9pmoA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2952 bytes --]
Hi,
On Fri, Mar 03, 2023 at 03:05:41PM -0800, Jason Gerecke wrote:
> Apologies for the delay in replying.
>
> First off: as an immediate action, I'm thinking of changing the Wacom
> driver to do lazy creation of the power_supply device. This would mean
> that rather than creating it at the same time as the input device, we
> would wait until we receive some kind of affirmative indication of a
> battery being present. Most Wacom peripherals report battery status in
> a "heartbeat" report that is sent every few seconds, so there wouldn't
> be much change for the typical user (just a few-second delay between
> connecting the hardware and a power_supply device being created). In
> the case of the "component" devices that are built into laptops and
> other computers, however, the battery status is only reported while
> the pen is actually in proximity. For users like you who don't own (or
> never use) a pen, this means that our driver would never create a
> power_supply device -- preventing GNOME from showing a battery that
> isn't relevant. I'm working on a patch set that does this but need a
> bit more time to finish it.
>
> That's only a partial solution, however. If a component user were to
> bring a pen into prox even just briefly, then a power_supply device
> would be created and not go away until the user reboots. The pen's
> battery status will become stale at some point in time though --
> self-discharge, use of the pen on another device, and even just simple
> irrelevance if the user hasn't used the pen in a while (do I care that
> the pen which I left at home is at 50% battery?). I agree that it
> makes sense for userspace to hide the battery after a while due to
> things like this. Are there new signals that the kernel should be
> providing to userspace (e.g. an attribute that indicates if we're in
> communication with power_supply? an attribute signaling that data
> might be stale)? Or are the signals that are already provided
> sufficient (e.g. should GNOME just hide power_supply devices that are
> in an "Unknown" state? or maybe hide power_supplies which haven't been
> updated in more than 1 hour?)
Can't you just unregister the power-supply device if there hasn't
been any heartbeat for some minutes and go back to the init state
(i.e. the one where you are waiting for a heartbeat to appear for
the first time)?
> I've added the power_supply list and maintainer for some additional
> viewpoints on the second paragraph... If there are questions about how
> the Wacom hardware and its battery reporting works, I'm happy to
> provide answers...
I think the problem you have is quite specific to the Wacom
hardware. Usually wireless devices are either connected or
disconnected and drivers unregister the battery device on
disconnect. So I think this logic belongs into Wacom specific
code and not in generic power-supply core code.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2 0/2] Input: hideep - 2 HiDeep touchscreen patches
From: Hans de Goede @ 2023-03-03 22:21 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Hans de Goede, devicetree, linux-input
Hi Dmitry,
Here are 2 patches for the HiDeep touchscreen driver,
new in v2 is the addition of the second patch, patch 1/2
really is just a resend.
Regards,
Hans
Hans de Goede (2):
Input: hideep - Silence error in SW_RESET()
Input: hideep - Optionally reset controller work mode to native HiDeep
protocol
.../bindings/input/touchscreen/hideep.txt | 1 +
drivers/input/touchscreen/hideep.c | 23 ++++++++++++++++++-
2 files changed, 23 insertions(+), 1 deletion(-)
--
2.39.1
^ permalink raw reply
* Re: "proximity" attribute for input devices
From: Jason Gerecke @ 2023-03-03 23:05 UTC (permalink / raw)
To: Limonciello, Mario
Cc: linux-input@vger.kernel.org, Bastien Nocera, ping.cheng@wacom.com,
jason.gerecke@wacom.com, Sebastian Reichel, linux-pm
In-Reply-To: <MN0PR12MB6101F4408960BDB9CF63DD53E2AB9@MN0PR12MB6101.namprd12.prod.outlook.com>
Apologies for the delay in replying.
First off: as an immediate action, I'm thinking of changing the Wacom
driver to do lazy creation of the power_supply device. This would mean
that rather than creating it at the same time as the input device, we
would wait until we receive some kind of affirmative indication of a
battery being present. Most Wacom peripherals report battery status in
a "heartbeat" report that is sent every few seconds, so there wouldn't
be much change for the typical user (just a few-second delay between
connecting the hardware and a power_supply device being created). In
the case of the "component" devices that are built into laptops and
other computers, however, the battery status is only reported while
the pen is actually in proximity. For users like you who don't own (or
never use) a pen, this means that our driver would never create a
power_supply device -- preventing GNOME from showing a battery that
isn't relevant. I'm working on a patch set that does this but need a
bit more time to finish it.
That's only a partial solution, however. If a component user were to
bring a pen into prox even just briefly, then a power_supply device
would be created and not go away until the user reboots. The pen's
battery status will become stale at some point in time though --
self-discharge, use of the pen on another device, and even just simple
irrelevance if the user hasn't used the pen in a while (do I care that
the pen which I left at home is at 50% battery?). I agree that it
makes sense for userspace to hide the battery after a while due to
things like this. Are there new signals that the kernel should be
providing to userspace (e.g. an attribute that indicates if we're in
communication with power_supply? an attribute signaling that data
might be stale)? Or are the signals that are already provided
sufficient (e.g. should GNOME just hide power_supply devices that are
in an "Unknown" state? or maybe hide power_supplies which haven't been
updated in more than 1 hour?)
I've added the power_supply list and maintainer for some additional
viewpoints on the second paragraph... If there are questions about how
the Wacom hardware and its battery reporting works, I'm happy to
provide answers...
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
On Thu, Feb 23, 2023 at 7:39 AM Limonciello, Mario
<Mario.Limonciello@amd.com> wrote:
>
> [Public]
>
> Hello,
>
> A problem was found that a Wacom device's stylus battery showed up in GNOME even though the stylus wasn't near by.
> As part of discussing how to handle it Bastien proposes a new sysfs attribute "proximity" to let userspace know this.
>
> He asked[1] to start the discussion on Linux-input ML.
>
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=217062#c7
>
> Thanks,
^ permalink raw reply
* [PATCH v2 2/2] Input: hideep - Optionally reset controller work mode to native HiDeep protocol
From: Hans de Goede @ 2023-03-03 22:21 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Hans de Goede, devicetree, linux-input
In-Reply-To: <20230303222113.285546-1-hdegoede@redhat.com>
The HiDeep IST940E touchscreen controller used on the Lenovo Yoga Book X90F
convertible comes up in HID mode by default.
This works well on the X91F Windows model where the touchscreen is
correctly described in ACPI and ACPI takes care of controlling
the reset GPIO and regulators.
But the X90F ships with Android and the ACPI tables on this model don't
describe the touchscreen. Instead this is hardcoded in the vendor kernel.
The vendor kernel uses the touchscreen in native HiDeep 20 (2.0?) protocol
mode and switches the controller to this mode by writing 0 to reg 0x081e.
Adjusting the i2c-hid code to deal with the reset-gpio and regulators on
this non devicetree (but rather broken ACPI) convertible is somewhat tricky
and the native protocol reports ABS_MT_PRESSURE and ABS_MT_TOUCH_MAJOR
which are not reported in HID mode, so it is preferable to use the native
mode.
Add support to the hideep driver to reset the work-mode to the native
HiDeep protocol to allow using it on the Lenovo Yoga Book X90F.
This is guarded behind a new "hideep,reset-work-mode" boolean property,
to avoid changing behavior on other devices.
For the record: I did test using the i2c-hid driver with some quick hacks
and it does work. The I2C-HID descriptor is available from address 0x0020,
just like on the X91F Windows model.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
.../bindings/input/touchscreen/hideep.txt | 1 +
drivers/input/touchscreen/hideep.c | 16 ++++++++++++++++
2 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
index a47c36190b01..68bb9f8dcc30 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
@@ -17,6 +17,7 @@ Optional properties:
- linux,keycodes : Specifies an array of numeric keycode values to
be used for reporting button presses. The array can
contain up to 3 entries.
+- hideep,reset-work-mode: bool, reset touch report format to the native HiDeep protocol
Example:
diff --git a/drivers/input/touchscreen/hideep.c b/drivers/input/touchscreen/hideep.c
index 373c1269485f..452914b78bf9 100644
--- a/drivers/input/touchscreen/hideep.c
+++ b/drivers/input/touchscreen/hideep.c
@@ -35,6 +35,7 @@
#define HIDEEP_EVENT_ADDR 0x240
/* command list */
+#define HIDEEP_WORK_MODE 0x081e
#define HIDEEP_RESET_CMD 0x9800
/* event bit */
@@ -964,6 +965,17 @@ static const struct attribute_group hideep_ts_attr_group = {
.attrs = hideep_ts_sysfs_entries,
};
+static void hideep_set_work_mode(struct hideep_ts *ts)
+{
+ /*
+ * Reset touch report format to the native HiDeep 20 protocol if requested.
+ * This is necessary to make touchscreens which come up in I2C-HID mode
+ * work with this driver.
+ */
+ if (device_property_read_bool(&ts->client->dev, "hideep,reset-work-mode"))
+ regmap_write(ts->reg, HIDEEP_WORK_MODE, 0x00);
+}
+
static int __maybe_unused hideep_suspend(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
@@ -987,6 +999,8 @@ static int __maybe_unused hideep_resume(struct device *dev)
return error;
}
+ hideep_set_work_mode(ts);
+
enable_irq(client->irq);
return 0;
@@ -1063,6 +1077,8 @@ static int hideep_probe(struct i2c_client *client)
return error;
}
+ hideep_set_work_mode(ts);
+
error = hideep_init_input(ts);
if (error)
return error;
--
2.39.1
^ permalink raw reply related
* [PATCH v2 1/2] Input: hideep - Silence error in SW_RESET()
From: Hans de Goede @ 2023-03-03 22:21 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Hans de Goede, devicetree, linux-input
In-Reply-To: <20230303222113.285546-1-hdegoede@redhat.com>
On some models the first HIDEEP_SYSCON_WDT_CON write alone is enough to
cause the controller to reset, causing the second write to fail:
i2c-hideep_ts: write to register 0x52000014 (0x000001) failed: -121
Switch this write to a raw hideep_pgm_w_mem() to avoid an error getting
logged in this case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/input/touchscreen/hideep.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/hideep.c b/drivers/input/touchscreen/hideep.c
index ff4bb4c14898..373c1269485f 100644
--- a/drivers/input/touchscreen/hideep.c
+++ b/drivers/input/touchscreen/hideep.c
@@ -271,9 +271,14 @@ static int hideep_pgm_w_reg(struct hideep_ts *ts, u32 addr, u32 val)
#define SW_RESET_IN_PGM(clk) \
{ \
+ __be32 data = cpu_to_be32(0x01); \
hideep_pgm_w_reg(ts, HIDEEP_SYSCON_WDT_CNT, (clk)); \
hideep_pgm_w_reg(ts, HIDEEP_SYSCON_WDT_CON, 0x03); \
- hideep_pgm_w_reg(ts, HIDEEP_SYSCON_WDT_CON, 0x01); \
+ /* \
+ * The first write may already cause a reset, use a raw \
+ * write for the second write to avoid error logging. \
+ */ \
+ hideep_pgm_w_mem(ts, HIDEEP_SYSCON_WDT_CON, &data, 1); \
}
#define SET_FLASH_PIO(ce) \
--
2.39.1
^ permalink raw reply related
* Re: [PATCH v5 00/18] Self-encapsulate the thermal zone device structure
From: Rafael J. Wysocki @ 2023-03-03 19:48 UTC (permalink / raw)
To: Daniel Lezcano
Cc: rafael, linux-pm, linux-kernel, Zhang Rui, Len Brown,
Damien Le Moal, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team, Jean Delvare, Guenter Roeck,
Jonathan Cameron, Lars-Peter Clausen, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Dmitry Torokhov, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Ido Schimmel,
Petr Machata, Gregory Greenman, Kalle Valo, Sebastian Reichel,
Liam Girdwood, Mark Brown, Miquel Raynal, Amit Kucheria,
Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Markus Mayer, Support Opensource, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Thara Gopinath,
Niklas Söderlund, Heiko Stuebner, Bartlomiej Zolnierkiewicz,
Krzysztof Kozlowski, Alim Akhtar, Orson Zhai, Baolin Wang,
Chunyan Zhang, Vasily Khoruzhick, Yangtao Li, Thierry Reding,
Jonathan Hunter, Talel Shenhar, Eduardo Valentin, Keerthy,
Kunihiko Hayashi, Masami Hiramatsu, Matthias Brugger,
AngeloGioacchino Del Regno, Stefan Wahren, Zheng Yongjun, Yang Li,
Srinivas Pandruvada, Daniel Golle, Balsam CHIHI, Mikko Perttunen,
linux-acpi, linux-ide, linux-arm-kernel, linux-hwmon, linux-iio,
linux-sunxi, linux-input, netdev, linux-wireless,
linux-rpi-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, linux-samsung-soc, linux-tegra, linux-omap,
linux-mediatek
In-Reply-To: <1d3da42e-2499-7ff6-50fa-048a720e855f@linaro.org>
Hi Daniel,
On Fri, Mar 3, 2023 at 10:24 AM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
>
> Hi Rafael,
>
> Do we have enough ack to apply this series, is it for you ?
I've just queued it up for 6.4.
It will reach linux-next and the thermal branch some time next week,
but I will be traveling, so there may be delays.
Thanks!
^ permalink raw reply
* [PATCH] Input: i8042 - Add quirk for Fujitsu Lifebook A574/H
From: Jonathan Denose @ 2023-03-03 15:26 UTC (permalink / raw)
To: LKML
Cc: Jonathan Denose, Dmitry Torokhov, Hans de Goede, Huacai Chen,
Mattijs Korpershoek, Takashi Iwai, Werner Sembach, Wolfram Sang,
linux-input
Fujitsu Lifebook A574/H requires the nomux option to properly
probe the touchpad, especially when waking from sleep.
Signed-off-by: Jonathan Denose <jdenose@google.com>
---
drivers/input/serio/i8042-acpipnpio.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/input/serio/i8042-acpipnpio.h b/drivers/input/serio/i8042-acpipnpio.h
index efc61736099b..fe7ffe30997c 100644
--- a/drivers/input/serio/i8042-acpipnpio.h
+++ b/drivers/input/serio/i8042-acpipnpio.h
@@ -610,6 +610,14 @@ static const struct dmi_system_id i8042_dmi_quirk_table[] __initconst = {
},
.driver_data = (void *)(SERIO_QUIRK_NOMUX)
},
+ {
+ /* Fujitsu Lifebook A574/H */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "FMVA0501PZ"),
+ },
+ .driver_data = (void *)(SERIO_QUIRK_NOMUX)
+ },
{
/* Gigabyte M912 */
.matches = {
--
2.40.0.rc0.216.gc4246ad0f0-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox