From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: "Michał Pecio" <michal.pecio@gmail.com>,
linux-usb@vger.kernel.org, linux-media@vger.kernel.org,
gregkh@linuxfoundation.org, laurent.pinchart@ideasonboard.com,
hdegoede@redhat.com, Thinh.Nguyen@synopsys.com,
"Amardeep Rai" <amardeep.rai@intel.com>,
"Kannappan R" <r.kannappan@intel.com>,
"Alan Stern" <stern@rowland.harvard.edu>
Subject: Re: [PATCH v4 3/4] USB: Add a function to obtain USB version independent maximum bpi value
Date: Mon, 18 Aug 2025 12:13:05 +0000 [thread overview]
Message-ID: <aKMY0XPLmK-TOWIt@kekkonen.localdomain> (raw)
In-Reply-To: <aKMOBPTqZX_yJjOv@kekkonen.localdomain>
Hi Mathias,
On Mon, Aug 18, 2025 at 11:27:00AM +0000, Sakari Ailus wrote:
> Hi Mathias,
>
> On Mon, Aug 18, 2025 at 10:32:48AM +0300, Mathias Nyman wrote:
> > Hi
> >
> > On 18.8.2025 9.08, Sakari Ailus wrote:
> > > Hi Michał,
> > >
> > > Thank you for the review.
> > >
> > > On Wed, Aug 13, 2025 at 04:49:58PM +0200, Michał Pecio wrote:
> > > > On Tue, 12 Aug 2025 16:24:44 +0300, Sakari Ailus wrote:
> > > > > From: "Rai, Amardeep" <amardeep.rai@intel.com>
> > > > >
> > > > > Add usb_endpoint_max_isoc_bpi() to obtain maximum bytes per interval for
> > > > > isochronous endpoints in a USB version independent way.
> > > > >
> > > > > Signed-off-by: Rai, Amardeep <amardeep.rai@intel.com>
> > > > > Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
> > > > > Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > > Reviewed-by: Hans de Goede <hansg@kernel.org>
> > > >
> > > > Hi,
> > > >
> > > > This is practically identical to xhci_get_max_esit_payload().
> > > >
> > > > Couldn't xhci also use this helper now, to reduce duplication and
> > > > ensure that it has the same idea of ESIT payload as class drivers?
> > > >
> > > > Note that this here would need to also accept interrupt EPs:
> > > > > +{
> > > > > + if (usb_endpoint_type(&ep->desc) != USB_ENDPOINT_XFER_ISOC)
> > > > > + return 0;
> > >
> > > Sounds reasonable, I'll see how to best take that into account in v5.
> > >
> > > I wonder if I should adopt the name from the xHCI variant as the function
> > > would be also used for interrupt endpoints.
> > >
> >
> > I think the "ESIT" acronym (Endpoint Service Interval Time) is very xHCI
> > spec specific. Usb spec usually refers to isoc and interrupt endpoints as
> > "periodic"
> >
> > how about one of these:
> > usb_endpoint_max_periodic_bytes()
> > usb_endpoint_max_periodic_payload()
> > usb_endpoint_max_periodic_bpi()
>
> How about usb_endpoint_max_si_payload() ("si" being for service interval)?
I somehow missed your latter sentence earlier. I'm totally fine with these,
perhaps I'm slightly leaning towards usb_endpoint_max_periodic_payload()
but let's see what others think.
--
Kind regards,
Sakari Ailus
next prev parent reply other threads:[~2025-08-18 12:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-12 13:24 [PATCH v4 0/4] eUSB2 Double Isochronous IN Bandwidth support Sakari Ailus
2025-08-12 13:24 ` [PATCH v4 1/4] xhci: Add host support for eUSB2 double isochronous bandwidth devices Sakari Ailus
2025-08-18 9:50 ` Michał Pecio
2025-08-18 15:30 ` Mathias Nyman
2025-08-19 14:01 ` Sakari Ailus
2025-08-20 8:24 ` Sakari Ailus
2025-08-20 8:43 ` Michał Pecio
2025-08-20 13:19 ` Sakari Ailus
2025-08-12 13:24 ` [PATCH v4 2/4] USB: core: support eUSB2 double bandwidth large isoc URB frames Sakari Ailus
2025-08-12 13:24 ` [PATCH v4 3/4] USB: Add a function to obtain USB version independent maximum bpi value Sakari Ailus
2025-08-12 13:58 ` Alan Stern
2025-08-13 14:49 ` Michał Pecio
2025-08-18 6:08 ` Sakari Ailus
2025-08-18 7:32 ` Mathias Nyman
2025-08-18 8:37 ` Michał Pecio
2025-08-18 11:27 ` Sakari Ailus
2025-08-18 12:13 ` Sakari Ailus [this message]
2025-08-18 13:39 ` Alan Stern
2025-08-12 13:24 ` [PATCH v4 4/4] media: uvcvideo: eUSB2 double isochronous bandwidth support Sakari Ailus
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=aKMY0XPLmK-TOWIt@kekkonen.localdomain \
--to=sakari.ailus@linux.intel.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=amardeep.rai@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=michal.pecio@gmail.com \
--cc=r.kannappan@intel.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.