On Mon, Mar 6, 2023 at 11:49 AM Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> 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
