All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Daniel Kaehn <kaehndan@gmail.com>,
	Hans de Goede <hdegoede@redhat.com>,
	robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	jikos@kernel.org, bartosz.golaszewski@linaro.org,
	dmitry.torokhov@gmail.com, devicetree@vger.kernel.org,
	linux-input@vger.kernel.org, ethan.twardy@plexus.com
Subject: Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
Date: Mon, 6 Mar 2023 12:49:25 +0200	[thread overview]
Message-ID: <ZAXFNRuALYpXgL6F@smile.fi.intel.com> (raw)
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



  reply	other threads:[~2023-03-06 10:49 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27 14:07 [PATCH v8 0/3] Firmware Support for USB-HID Devices and CP2112 Danny Kaehn
2023-02-27 14:07 ` [PATCH v8 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge Danny Kaehn
2023-02-27 14:07 ` [PATCH v8 2/3] HID: usbhid: Share USB device firmware node with child HID device Danny Kaehn
2023-02-27 14:07 ` [PATCH v8 3/3] HID: cp2112: Fwnode Support Danny Kaehn
2023-02-27 23:07   ` Andy Shevchenko
2023-02-28 19:05     ` Daniel Kaehn
2023-03-01 14:59       ` Andy Shevchenko
2023-03-01 15:04         ` Andy Shevchenko
2023-03-02 17:06         ` Benjamin Tissoires
2023-03-06 10:49           ` Andy Shevchenko [this message]
2023-03-06 12:36             ` Benjamin Tissoires
2023-03-06 13:07               ` Andy Shevchenko
2023-03-06 14:48                 ` Benjamin Tissoires
2023-03-06 17:01                   ` Andy Shevchenko
2023-03-06 19:40                     ` Daniel Kaehn
2023-03-06 20:36                       ` Andy Shevchenko
2023-03-07 13:17                         ` Benjamin Tissoires
2023-03-07 13:53                           ` Daniel Kaehn
2023-03-07 14:48                             ` Benjamin Tissoires
2023-03-07 18:18                               ` Andy Shevchenko
2023-03-08 15:26                                 ` Benjamin Tissoires
2023-03-08 15:37                                   ` Daniel Kaehn
2023-03-08 15:55                                     ` Benjamin Tissoires
2023-03-08 16:30                                       ` Andy Shevchenko
2023-03-08 16:36                                         ` Andy Shevchenko
2023-03-08 18:32                                           ` Daniel Kaehn
2023-03-09 11:43                                             ` Andy Shevchenko
2023-03-09 11:56                                               ` Andy Shevchenko
2023-03-09  9:38                                         ` Benjamin Tissoires
2023-03-09 13:50                                           ` Andy Shevchenko
2023-03-08 16:20                                   ` Andy Shevchenko
2023-03-07 18:15                             ` Andy Shevchenko
2023-03-07 18:14                           ` Andy Shevchenko
2023-03-07 19:57                             ` Daniel Kaehn
2023-03-08 12:41                               ` Andy Shevchenko

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=ZAXFNRuALYpXgL6F@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=benjamin.tissoires@redhat.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=ethan.twardy@plexus.com \
    --cc=hdegoede@redhat.com \
    --cc=jikos@kernel.org \
    --cc=kaehndan@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-input@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.