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