usb: dwc3: debugfs: Dump internal states

[Felipe Balbi <balbi@kernel.org>]

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.