Hi,
On 10/02/2013 08:39 PM, Sarah Sharp wrote:
On Wed, Oct 02, 2013 at 10:22:52AM -0400, Alan Stern wrote:
snip
We should consider this before rushing into a new API.
Yes, I agree. :) That's why I'd like to see some cases in the media
drivers code where it could benefit from changing the
Hi Sarah,
Em Tue, 1 Oct 2013 13:45:54 -0700
Sarah Sharp sarah.a.sh...@linux.intel.com escreveu:
On Tue, Oct 01, 2013 at 10:01:08PM +0300, Xenia Ragiadakou wrote:
Hi Sarah,
I read the mail on 'possible conflict between xhci_hcd and a patched
usbhid'.
For reference to others:
On Tue, 1 Oct 2013, Sarah Sharp wrote:
When you say a new API, what do you mean? New functions in usbcore
to be used by usb device drivers?
Yes. You would export the function in the USB core, and put a prototype
in a USB include file (probably in include/linux/usb.h). Let's say that
On Wed, 2 Oct 2013, Mauro Carvalho Chehab wrote:
Let me see if I understand the changes at the media drivers. So, please
correct me if I got it wrong.
I'm yet to get any USB 3.0 media device, although it is common to connect
an USB 1.1 or USB 2.0 device on a USB 3.0 host port.
So, for
Em Wed, 02 Oct 2013 11:00:13 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu escreveu:
On Wed, 2 Oct 2013, Mauro Carvalho Chehab wrote:
Let me see if I understand the changes at the media drivers. So, please
correct me if I got it wrong.
I'm yet to get any USB 3.0 media device,
On Wed, 2 Oct 2013, Mauro Carvalho Chehab wrote:
So, there's no need to call usb_change_ep_bandwidth().
That's right.
If so, then usb_change_ep_bandwidth() as a quirk, if bInterval
or wMaxPacketSize were improperly filled.
Right?
Or if the values are correct, but the
Em Wed, 02 Oct 2013 12:38:14 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu escreveu:
On Wed, 2 Oct 2013, Mauro Carvalho Chehab wrote:
So, there's no need to call usb_change_ep_bandwidth().
That's right.
If so, then usb_change_ep_bandwidth() as a quirk, if bInterval
or
On Wed, Oct 02, 2013 at 12:16:04AM +0300, Xenia Ragiadakou wrote:
On 10/01/2013 11:45 PM, Sarah Sharp wrote:
Sure. I would actually suggest you first finish up the patch to issue a
configure endpoint if userspace wants to clear a halt, but the endpoint
isn't actually halted. Did your most
On Wed, Oct 02, 2013 at 10:22:52AM -0400, Alan Stern wrote:
On Tue, 1 Oct 2013, Sarah Sharp wrote:
When you say a new API, what do you mean? New functions in usbcore
to be used by usb device drivers?
Yes. You would export the function in the USB core, and put a prototype
in a USB
On Wed, 2 Oct 2013, Sarah Sharp wrote:
In particular, do we want to go around changing single endpoints, one
at a time? Or do we want to change all the endpoints in an interface
at once?
Given that a change to one endpoint may require the entire schedule to
be recomputed, it
On Wed, 2 Oct 2013, Alan Stern wrote:
Ok, so it sounds like we want to keep the changes the endpoints across
alt setting changes.
No, just the opposite. That was the point I was trying to make. Any
changes to ep5 in altsetting 0 (for example) will have no effect on ep1
On 10/01/2013 11:45 PM, Sarah Sharp wrote:
On Tue, Oct 01, 2013 at 10:01:08PM +0300, Xenia Ragiadakou wrote:
Hi Sarah,
I read the mail on 'possible conflict between xhci_hcd and a patched
usbhid'.
For reference to others:
http://marc.info/?l=linux-usbm=138064948726038w=2
12 matches
Mail list logo
