f_hid GET_REPORT extension

f_hid GET_REPORT extension

[Michael Nazzareno Trimarchi]

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?

Michael

Re: f_hid GET_REPORT extension

[Greg Kroah-Hartman]

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.

Also, why sysfs?

thanks,

greg k-h

Re: f_hid GET_REPORT extension

[Michael Nazzareno Trimarchi]

Hi Greg

On Mon, Jun 27, 2022 at 9:21 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> 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

Michael

>
> thanks,
>
> greg k-h

Re: f_hid GET_REPORT extension

[Greg Kroah-Hartman]

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@linuxfoundation.org> 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

Re: f_hid GET_REPORT extension

[Michael Nazzareno Trimarchi]

Hi Greg

On Mon, Jun 27, 2022 at 2:05 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> 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@linuxfoundation.org> 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