Re: Options for forcing dwc3 gadget to only accept superspeed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On tir, 2020-05-12 at 23:47 -0500, Sid Spry wrote:
> Hello again, I'm terribly sorry for the double post. Claus, you might
> try detecting the speed of the connection and re-enumerating if
> necessary. It would avoid noncompliance with the spec and is probably
> the easiest option.
> 
> Unsure of how this would be done with a C manifestation of functionfs
> code but echoing "" to the UDC pseudofile under
> /sys/kernel/config/usb_gadget/${your_gadget} will allow you to set
> everything up again and reenumerate.
> 
> On Tue, May 12, 2020, at 11:43 PM, Sid Spry wrote:
> > Have you tried only providing a SS configuration? If that fails for
> > some reason I suspect the next course of action would be to see
> > why, and patch the driver so it does not.
> > 
> > Out of curiosity, which SoC are you using?
> > 

Hi Sid.

Thanks for both your replies. Will answer the last question first. It
is the Xilinx Zynq UltraScale+ MPSoC, also just known as ZynqMP.

I remember vaguely testing only SS configuration for an older kernel,
where it got a fault because somewhere the configurations was indexed
by [0], e.g. just indexing the full-speed descriptor directly. This
might changed by now.

Regarding just enumerating. I have thought about it, and it might be
what I end up implementing no matter what. The not so nice part is if
the host side is Windows, my impression from doing it like this, would
be that you get the "device appeared" / "device not safely removed"
style of messages. Can't remember the exact wording.

Just as a background in why I am looking into doing it like this. For
10 years ago I worked on some USB 3 devices. Here the USB2 part was a
hard-block, and the USB3 part was a soft-core in FPGA logic. I
encountered a number of, should we call it implementation differences,
in the USB 3 hosts. E.g. issues like when the device and host did not
agree on link training (Ux exit) etc.
As the link control of switching between the hard-block and the soft-
core was done in firmware, it was pretty easy for me to make an option
for being non-compliment and making the link retry Super-Speed, and by
that hide the "differences" for the end-user, and just have working
system.


Thanks
/Claus




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux