0

My USB device (a OnePlus 10T smartphone) connected to a CentOS 7 server occasionally shows up with "wrong" (Google's) vendor:product IDs in lsusb output upon reboot:

Bus 002 Device 003: ID 18d1:4ee8 Google Inc. Nexus/Pixel Device (MIDI)

When I disconnect and reconnect its USB cable they usually change to the right ones (22d9:2765 OPPO), but is there a way to force the right ones onto it automatically somehow, e.g. using udev? Resetting USB port (e.g. with the tools like usbreset, uhubctl etc) doesn't seem to help.

Thanks in advance!

2 Answers 2

4

No, you can't do that. This information is read from the device by the hardware during device recognition and then made available to the kernel.

What you can do is you can force some driver to recognize this device:

echo 2-7:1.0 > /sys/bus/usb/drivers/<drivername>/bind

This 2-7:1.0 is a USB bus address of the device, you can infer it from lsusb -t output. You can even create an udev rule to do this automatically.

However, this may not help. I think your phone presents not the expected PID:VID pair because it is initialized in different mode, where it is really different device. For example, my phone asks "which mode to run as" when it finds out I connected it to the computer, with choices like "USB storage" or "MTP device" or "Just charge", and it is presented to the computer in different ways and gets bound to different drivers. Force binding the device to another driver than it gets bound to automatically will definitely not work in my case.

Why your phone gets sometimes initialized in the wrong way is a quite different question. Better address that rather than trying to force things.

4
  • I tried unbind followed by bind as suggested in several other threads but that doesn't help. Presenting itself with "wrong" IDs seems to be a known anomaly: I understand it's 'cos Fastboot kicks in first, however what I don't get is why even rebooting the server while the phone is fully booted into the Android doesn't help it re-register properly. I'm happy to change whatever needs changing at the phone side if that helps (once I get there next time to regain access to it now).
    – dandreye
    Commented Feb 14, 2023 at 11:56
  • btw when I was there connecting and reconnecting the phone it was definitely prompting that mode selection every time indeed. However IIRC even when I didn't select any (usually I'd select MTP mode there) it'd still present itself with the "good" IDs. One thing I learned was that it's critical to reconnect the cable, and - interestingly - exactly at the phone side. Meanwhile rebooting the phone or the server never helped.
    – dandreye
    Commented Feb 14, 2023 at 12:15
  • It that USB micro AB connector? It is most "fancy" connector of all of them. Commented Feb 14, 2023 at 12:22
  • Nope, it's a USB-C one.
    – dandreye
    Commented Feb 14, 2023 at 12:40
1

You can't. That's a fundamental property of the USB device. It's not under control of your PC.

What you could do is reset the bus using a udev rule to make the device re-register. But that sounds like a pretty bad idea, because it would throw out all other devices on that bus, usually, and that can lead to data loss in case of storage media etc.

So all in all, if you want a USB device to behave differently than it does, then you'll have to change the device's firmware, not the host's software.

5
  • resetting the bus sounds promising as I have no other USB devices there anyway. Any chance to share a suitable udev rule for that?
    – dandreye
    Commented Feb 14, 2023 at 11:35
  • Fiddling some usb quirk & rebuild kernel could possibly help
    – MC68020
    Commented Feb 14, 2023 at 11:35
  • @MC68020 how? That would not make the phone reboot. Commented Feb 14, 2023 at 11:47
  • @dandreye no, don't have one, and I promise, it's not a good idea. I regret mentioning it. Source: dealing with loads of crappy legacy USB devices. This is just a fun way to find more unreliable USB device behaviour. Commented Feb 14, 2023 at 11:49
  • @MarcusMüller: Understood: no worries )
    – dandreye
    Commented Feb 14, 2023 at 11:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .