On Wed, Apr 10, 2024, Manan Aurora wrote: > Hi Thinh, > > I'm working on a patch to bring EBC support back, I had a doubt > regarding some of the required corrections though (inlined) > > Please take a look and advise, I'll proceed accordingly. > > > On Fri, Feb 9, 2024 at 6:55 AM Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> wrote: > > > > This reverts commit 398aa9a7e77cf23c2a6f882ddd3dcd96f21771dc. > > > > The update to the gadget API to support EBC feature is incomplete. It's > > missing at least the following: > > * New usage documentation > I will address this > > * Gadget capability check > > * Condition for the user to check how many and which endpoints can be > > used as "fifo_mode" > The easiest option seems to be to add a new function that lets users > specifically request > fifo_mode endpoints eg: usb_fifo_mode_ep_autoconfig_ss > This function will cover ensuring that the device supports > fifo_endpoints and returning a suitable > endpoint (if available) and NULL otherwise. This can be indicated by > adding a new bit to > the existing ep_caps structure. > Does this seem like an acceptable solution? That sounds fine to me. For the naming, perhaps just name it as EBC for External Buffer Control and provide proper description in documentation. "fifo_mode" may not be clear. Maybe usb_ep_autoconfig_ss_with_ebc()? How are you planning to implement the above function? Are you going to apply the DWC_usb3x specific requirements directly or implement gadget_ops->match_ep() to properly return the right endpoint base on the endpoint desc? As you're aware, EBC is only applicable to non-streams bulk only. Also it doesn't apply to full-speed. > > > * Description of how it can affect completed request (e.g. dwc3 won't > > update TRB on completion -- ie. how it can affect request's actual > > length report) > I will remove the NO_WB bit for the EBC endpoint and leave it up to > the user to enable/disable this Thanks, Thinh
