Hi Greg
On Mon, Jun 27, 2022 at 2:05 PM Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> 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.
Thank you for the explanation. I will prototype it
Michael
>
> greg k-h
