On Thu, May 11, 2017 at 10:19:30PM +0100, Rui Miguel Silva wrote:
> Hi Guenter,
> On Thu, May 11, 2017 at 10:14:15AM -0700, Guenter Roeck wrote:
> >On Thu, May 11, 2017 at 03:20:21PM +0100, Rui Miguel Silva wrote:
> >>This driver was using debugfs as a logging mechanism instead of the normal dev_*
> >>helpers. This patch changes this and move all calls to fusb302_log function to
> >>the correspondent dev_{err,dbg,info}.
> >>
> >>Since the debugfs interface was only used for logging, with this patch it became
> >>unused, so just remove it.
> >>
> >>Signed-off-by: Rui Miguel Silva <rmfrfs@xxxxxxxxx>
> >
> >Nack, sorry.
> >
> >This doesn't work; we tried it. Console logging affects timing, making
> >the driver unusable.
>
> Yeh, this driver is super verbose, maybe this could be a first
> step to strip some of messages, even though only with dev_dbg
> enable the verbose should affect timing. And the errors go to an
> expected location instead a debugfs interface.
>
Using debugfs and the verbosity was on purpose; after all, the
messages are only seen if someone actually looks at the debugfs
output. tcpm uses the same approach, and it is still extremely
useful to determine (after the fact) if some protocol exchange
went wrong and how.
dev_dbg() or similar debug output that slows down the protocol doesn't
help - it would only create heisenbugs.
Maybe we can drop all this at some point, eg when we move the driver(s)
out of staging. Someone suggested to use ptrace instead; maybe that would
work as well, and we should explore it.
Thanks,
Guenter
> And/Or using the debugfs to dump register values would help in
> real debug situations.
>
> Anyhow it is your call on this one.
> Dropping this patch from the series.
>
> Cheers,
> Rui
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
