cdc-wdm.c broke Synopsis USB HC

Bjørn Mork bjorn at mork.no
Wed Jun 18 10:53:08 PDT 2014


Interesting. Any ideas how/why it fails when we cancel/resubmit the urbs?

AFAIK, no mainline controller driver has any problems with the current driver strategy. Which is based on the idea that we should not read anything from the modems unless we have some userspace consumer.


Bjørn

On 18 June 2014 18:54:51 CEST, Markus Gothe <nietzsche at lysator.liu.se> wrote:
>Turned out that start submitting the validity urn when the driver is
>loaded (inspired by usbnet.c status-check),
>instead of enabling / disabling periodics and the URB upon open/release
>saved the controller from halting.
>
>:-)
>
>//M
>
>On 16 Jun 2014, at 22:32 , Markus Gothe <nietzsche at lysator.liu.se>
>wrote:
>
>> Hmm… I was thinking the HC could make this decision since it claims
>an IRQ.
>> 
>> Then how the driver should behave is another question. However the
>cdc-wdm approach seems to be kinda no-go on these controllers.
>> I succesfully patched the ECHI scheduler but then broken other
>functionality on a "hindenbug basis”. :-/ So I’ll better rewrite the
>validity URB int-callback.
>> 
>> And yes I guess you are correct, there should be a thread, task let
>or bottomhalf to poll the data IMO.
>> 
>> //M
>> 
>> On 16 Jun 2014, at 21:52 , Bjørn Mork <bjorn at mork.no> wrote:
>> 
>>> Markus Gothe <nietzsche at lysator.liu.se> writes:
>>> 
>>>> I think it is time for a redesign of the WDM driver. I havent read
>the
>>>> specs but in short it will cause timing issues with some SoC-hubs
>from
>>>> Synopsis. GobiNet also invokes the error halting the hub. Basically
>>>> both drivers shares a polling-routine based on sending the same
>>>> interrupt URB over and over again, hence creating a polling loop.
>>> 
>>> That's the way USB works...  The host polls.  If it doesn't then the
>>> device cannot send anything.
>>> 
>>>> For periodic transfers this seem to halt the Synopsis hub FUBAR. So
>is
>>>> there any pointers in the WMC documentation on how to let the
>>>> piggy-backing device create "real" IRQs when there is data to read?
>>> 
>>> A USB device cannot create "real" IRQs.
>>> 
>>> 
>>> 
>>> Bjørn
>> 
>> 
>> 
>> //Markus - The panama-hat hacker
>> 
>> _______________________________________________
>> libqmi-devel mailing list
>> libqmi-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>
>
>
>//Markus - The panama-hat hacker



More information about the libqmi-devel mailing list