From: Maxim Devaev <mdevaev@gmail.com>
To: "Maciej Żenczykowski" <maze@google.com>
Cc: balbi@kernel.org, stern@rowland.harvard.edu,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
ruslan.bilovol@gmail.com, mika.westerberg@linux.intel.com,
jj251510319013@gmail.com, linux-usb@vger.kernel.org,
Kernel hackers <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] usb: gadget: f_hid: optional SETUP/SET_REPORT mode
Date: Fri, 20 Aug 2021 17:36:32 +0300 [thread overview]
Message-ID: <20210820173632.053b1b2d@reki> (raw)
In-Reply-To: <CANP3RGejWk7Zj2XMGGPgrGMSjqRY+ZaVFha6jG720RCSF9HEkQ@mail.gmail.com>
Maciej Żenczykowski <maze@google.com> wrote:
> perhaps better to rephrase as 'the host ceases to change the status of
> the gadget/keyboard LEDs',
> unless this is actually driven by the keyboard as opposed to the other
> way round (which is what I'd expect from AT, PS/2 keyboards).
Since I'm describing the behavior on the gadget side,
it seemed to me that the explanation about the impossibility
of receiving it was more appropriate.
> Not clear what 'not poll' means here. Why would they (the host) need
> to poll an OUT endpoint?
Poll the IN Endpoint, fixed
> Additionally it seems like any keyboard gadget would want to default
> to the older more compatible mode?
> Or are there compatibility problems with it as well?
Yes, any keyboard should use SETUP/SET_REPORT if it wants maximum
compatibility. This mode has no problems with hosts. I suggest it
as optional only because for the last 9 years the default behavior
has been OUT Endpoint and in the place of those people who use it,
I would be upset if this was changed, since it could lead to strange
problems like lack of a queue and loss of events if f_hid is used
for data transmission, and not for emulating input devices.
> if you look down below, this isn't actually dynamic, should we just
> have hidg_interface_desc_{intout,ssreport} structs?
DYNAMIC is indirectly provided by the no_out_endpoints flag.
I preferred to avoid duplicating the code here.
> may be better to just use an if (hidg->use_out_ep) status =
> usb_assign_descriptors(...) else status = usb_assign_descriptors(...)
Yep, you're right
> maybe it would be better to use consistent naming...
>
> hidg->no_out_endpoint = opts->no_out_endpoint
>
> or call the option 'use_ssreport' instead of 'no_out_endpoint'
> (negatives are harder to think about)
Yea, I also thought about it and made such a name precisely
based on consistency. The rest of the code contains the out_ep
variable, so it was logical to make the use_out_ep flag.
In addition, there are no long names like *_out_endpoint anywhere.
At the same time, abbreviations are not used in configfs
and I didn't want to make a flag there that the user should change
to 0 if he does not want to use out endpoint. I would prefer
to leave it as it is, because it does not use negation logic,
and it will be easy for you to grep something like out_ep\>
> Anyway, nothing in here is particularly important, just loose thoughts.
> In general this seems pretty nice.
Thank you for the review! I will fix this and make a third version of the patch.
prev parent reply other threads:[~2021-08-20 14:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-14 3:12 [PATCH v2] usb: gadget: f_hid: optional SETUP/SET_REPORT mode Maxim Devaev
2021-08-19 21:13 ` Maciej Żenczykowski
2021-08-20 14:36 ` Maxim Devaev [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210820173632.053b1b2d@reki \
--to=mdevaev@gmail.com \
--cc=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jj251510319013@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=maze@google.com \
--cc=mika.westerberg@linux.intel.com \
--cc=ruslan.bilovol@gmail.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.