On Wed, Nov 07, 2018 at 12:45:50PM +0200, Felipe Balbi wrote: > > Hi, > > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > >> Thinh Nguyen <thinh.nguyen@xxxxxxxxxxxx> 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
