Hi, Bin Liu <b-liu@xxxxxx> writes: >>>>> I would also add a very verbose and descriptive comment on that >>>>> particular location so we never forget about these MUSB oddities next >>>>> time someone's looking at this. >>>> >>>> Also, leave the WARN() alone. We don't want FIFOFLUSH to ever fail. If >>>> it does, we're doing it wrong. >>>> >>> >>> Well, I have tried the changes you mentioned above, but the WARN() was >>> still triggered for dequeue all the tx urbs while disconnect the >>> device. >> >> then we need to figure out why isn't the patcket being flushed. Are you >> using double buffering ? Is a packet being loaded in the FIFO right now? >> Does it change if you set *only* FLUSHFIFO but *not* TXKPKTRDY ? > > Right now here have 3 problems: > > 1. tx fifo flush failed during device disconnect, it is harmless though; > 2. WARN() causes console log flooding in the case which multi (100+) tx > urbs queued; > 3. the 1ms delay causes disconnect delay in the case which multi tx urbs > queued; > > We know if #1 was solved, #2 & #3 would not happen, but the handling of > #2 & #3 in the driver is not correct. > > How about to address the #2 & #3 first, and leave #1 for another patch > since it would take some effort to find the root cause? > > To solve #2 & #3, > > 1. change WARN() to dev_err() so that kernel log by default still > shows not dev_err(), try dev_WARN_ONCE(). I still want the verbosity of a WARN(), but we can live with only one WARN(). > the issue but does not flood the console; > 2. add inline comment that #1 needs revisit; > 3. remove 1ms delay. yeah, 1ms does sound like a lot. > Please let me know if this is acceptable then I will send v3. if you use dev_WARN_ONCE() I can accept. sure. -- balbi
Attachment:
signature.asc
Description: PGP signature
