usb: dwc3: debugfs: Dump internal states

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Nov 07, 2018 at 12:45:50PM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> >> Thinh Nguyen <thinh.nguyen@synopsys.com> writes:
> >> >>>>> +static ssize_t dwc3_internal_states_write(struct file *file,
> >> >>>>> +		const char __user *ubuf, size_t count, loff_t *ppos)
> >> >>>> why is this necessary? Seems like it would be nicer to create a
> >> >>>> directory structure if the current operating mode is host so that we
> >> >>>> don't need to write anything.
> >> >>> Can you clarify more about the directory structure? Actually, I was
> >> >>> wondering what's the best way to do this also. The reason I want to
> >> >>> write to it is because the LSP selection for host is quite large (2^14).
> >> >> right, turn each of those into a directory of its own. If you don't want
> >> >> to or can't disclose proper names for those directories, just call them
> >> >> lsp0, lsp1, lsp2, and so on. Then a read of the file under lsp1
> >> >> directory would write and read the correct registers.
> >> >>
> >> >> Everything remains read-only.
> >> >
> >> > This means that there will be 16384 + 256 files create for host. It also
> >> > means that we need to kmalloc at least (16384 + 256) * (size of each
> >> > selection) so that each file knows what to print. On top of that, when
> >> > we change mode of operation (e.g. device->host), then we need to
> >> > create/destroy all these files. Is this the way to do it?
> >> 
> >> Hmm... indeed that's a lot. But since this is used only for debugging I
> >> wonder if we should care. Greg, Alan, what do you guys think? Do we
> >> create 16k files under debugfs or single file that needs to be written
> >> to before being read?
> >
> > 16k files under debugfs is crazy, don't do that :)
> 
> one file with write followed by read it is then :-p
> 
> > What type of interface would ever want such a thing?  I have not been
> > paying attention, but what is the end goal here?  What do you want to
> > expose in debugfs that is actually going to be useful?
> 
> internal debug information from dwc3's list processor (the HW
> itself). It's only useful for synopsys, really, as the content of such
> registers lacks documentation about how to decode it.

Ok, one file with crazy semantics is fine, remember the only "rule" for
debugfs is "there are no rules" :)

And of course, the normal operation of the driver should never require
debugfs to be present or even working.

thanks,

greg k-h