On Mon, Jun 27, 2022 at 10:02:27AM +0200, Michael Nazzareno Trimarchi wrote:
> Hi Greg
>
> On Mon, Jun 27, 2022 at 9:21 AM Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, Jun 27, 2022 at 09:06:05AM +0200, Michael Nazzareno Trimarchi wrote:
> > > Hi Felipe and Greg
> > >
> > > I'm starting to write some code to extend the GET_REPORT and let the
> > > userspace on the device side to pre-fill the answer on this request.
> > > Right now the answer is always 0. The idea is to create a sysfs
> > > support to fill reports struct on report request on the host side.
> > > This will help to
> > > emulate devices that export features report for example. As far as I
> > > understand the hidg side just use read and write and read is used to
> > > extract
> > > the result of SET_REPORT is that the gadget is properly configured. Is
> > > it the right direction?
> >
> > Without code, it is very hard to understand what you are doing here,
> > sorry.
> >
>
> Agree, I need only a suggestion what is the best way to expose it
>
> > Also, why sysfs?
>
> Let me clarify this point. Right now the userspace manage the set_report
>
> static ssize_t f_hidg_read(struct file *file, char __user *buffer,
> size_t count, loff_t *ptr)
> {
> struct f_hidg *hidg = file->private_data;
>
> if (hidg->use_out_ep)
> return f_hidg_intout_read(file, buffer, count, ptr);
> else
> return f_hidg_ssreport_read(file, buffer, count, ptr);
> }
>
> The report can be write from usb side and read on gadget side if use_out_ep
> is 0 (this is a configuration). Now, the answer to set_report is done
> sync on request
> and the usb message is buffered on the kernel side. During the
> get_report as far I understand we should reply
> the same way on bus. The idea is handle the type and report number and
> find it on a list of report that must be prepared
> on the gadget side. The hidg ops interface need to handle report
> preparation so I was thinking in two solutions:
> - sysfs kind of interface
> - ioctl like interface
sysfs is good for "one value per file", but not good for interactions
where you have back/forth from userspace to the kernel. ioctls are good
for "do something in the kernel and get this value back" type of
operation. configfs is good for initializing data for something before
you "finalize" it. So it all depends on what your userspace
interaction is going to be here as to what interface to use.
prototype it and see what works.
greg k-h
