usb: dwc3: debugfs: Dump internal states

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

On Wed, Nov 07, 2018 at 08:39:41AM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> 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 :)

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?

thanks,

greg k-h