gs while the mutex is
still held and checking for pending removes before allowing an open to
succeed.
Signed-off-by: Alan Stern
CC:
---
[as1920]
drivers/media/usb/usbvision/usbvision-video.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
Index: usb-devel/
sts
beforehand. Note that vidioc_querycap() is protected by
usbvision->v4l2_lock, acquired in a higher layer of the V4L2
subsystem.
Reported-and-tested-by: syzbot+7fa38a608b1075dfd...@syzkaller.appspotmail.com
Signed-off-by: Alan Stern
CC:
---
[as1919]
drivers/media/usb/usbvision/usbvision-v
On Wed, 2 Oct 2019, Tim Harvey wrote:
> On Tue, Oct 1, 2019 at 12:19 PM Alan Stern wrote:
> >
> > On Tue, 1 Oct 2019, Tim Harvey wrote:
> >
> > > On Thu, Sep 26, 2019 at 3:47 PM Tim Harvey wrote:
> > > >
> > > > Greetings,
> > >
gs while the mutex is
still held and checking for pending removes before allowing an open to
succeed.
Signed-off-by: Alan Stern
CC:
---
[as1920]
drivers/media/usb/usbvision/usbvision-video.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
Index: usb-devel/
sts
beforehand. Note that vidioc_querycap() is protected by
usbvision->v4l2_lock, acquired in a higher layer of the V4L2
subsystem.
Reported-and-tested-by: syzbot+7fa38a608b1075dfd...@syzkaller.appspotmail.com
Signed-off-by: Alan Stern
CC:
---
[as1919]
drivers/media/usb/usbvision/usbvision-v
-ENOSPC is getting returned from
> drivers/usb/host/ehci-sched.c:iso_stream_schedule()
>
> I feel perhaps this is something basic I don't understand regarding
> USB URB scheduling but I don't get why it occurs on the IMX6 ci_hdrc
> controller on not an XHCI controller.
after the structure has been
freed.
Clearly something is wrong, and I can't tell how this is all intended
to work. Is the deallocation supposed to occur at a later time?
Any ideas or suggestions?
Alan Stern
On Thu, 26 Sep 2019, syzbot wrote:
> Hello,
>
> syzbot has tested th
ol URBs. The DVB driver in question
uses bulk transfers.
xhci-hcd, on the other hand, does not use these tasklets (it doesn't
set the HCD_BH bit in the hc_driver's .flags member).
Alan Stern
st? The post says that the testing was done on an x86_64
machine.
> Gesendet: Montag, 08. Januar 2018 um 17:31 Uhr
> Von: "Alan Stern"
> An: "Josef Griebichler"
> Cc: "Mauro Carvalho Chehab" , "Greg Kroah-Hartman"
> , linux-...@vger.kernel.
dditional tcp load on raspberry.
>
> Unfortunately there's no usbmon or tshark on libreelec so I can't provide
> further logs.
Can you try running the same test on an x86_64 system?
Alan Stern
eduling parameters if needed, to adjust for
> > such use-cases (it was not really an admin choice before).
>
> Can't the ksoftirq patch be modified to only apply to the networking
> IRQ handling? That sounds less risky of affecting unrelated subsystems[1].
That might work. Or mo
On Mon, 8 Jan 2018, Mauro Carvalho Chehab wrote:
> Em Sun, 7 Jan 2018 10:41:37 -0500 (EST)
> Alan Stern escreveu:
>
> > On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote:
> >
> > > > > It seems that the original patch were designed to solve some IRQ
> >
to revert the kernel logic to prioritize latency instead of
> throughput.
It can't be done without pervasive changes to the USB subsystem, which
I would greatly prefer to avoid. Besides, this wouldn't really solve
the problem. Decreasing the latency for one device will cause it to be
increased for others.
Alan Stern
la kernel that gets plenty of video glitches?
Overall, this may be a very difficult problem to solve. The
4cd13c21b207 commit was intended to improve throughput at the cost of
increased latency. But then what do you do when the latency becomes
too high for the video subsystem to handle?
Alan Stern
On Thu, 30 Mar 2017, Oliver Neukum wrote:
> Am Donnerstag, den 30.03.2017, 11:55 -0400 schrieb Alan Stern:
> >
> > I'm pretty sure that usb-storage does not do this, at least, not when
> > operating in its normal Bulk-Only-Transport mode. It never tries to
> >
On Thu, 30 Mar 2017, Mauro Carvalho Chehab wrote:
> Em Thu, 30 Mar 2017 10:26:32 -0400 (EDT)
> Alan Stern escreveu:
>
> > On Thu, 30 Mar 2017, Oliver Neukum wrote:
> >
> > > > Btw, I'm a lot more concerned about USB storage drivers. When I was
>
te "the buffer can be
continuous", but that is certainly not what he meant.
Alan Stern
_disable() invoke the runtime PM suspend handler if the device is
> powered on ?
No, it doesn't, and neither does pm_runtime_put(). After all, if the
user has told the system not to do runtime PM on that device, it
doesn't make sense to call the runtime-suspend handler. But you can
always blame the user when this happens. :-)
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 25 Nov 2016, Laurent Pinchart wrote:
> Hi Alan,
Hello.
> On Friday 25 Nov 2016 10:21:21 Alan Stern wrote:
> > On Fri, 25 Nov 2016, Sakari Ailus wrote:
> > > On Thu, Nov 24, 2016 at 09:15:39PM -0500, Alan Stern wrote:
> > >> On Fri, 25 Nov 2016, Laurent P
On Fri, 25 Nov 2016, Sakari Ailus wrote:
> Hi Alan and others,
>
> On Thu, Nov 24, 2016 at 09:15:39PM -0500, Alan Stern wrote:
> > On Fri, 25 Nov 2016, Laurent Pinchart wrote:
> >
> > > Dear linux-pm developers, what's the suggested way to ensure that a
>
the best ways to ensure this are (1) audit the code, and
(2) actually try it.
I have a feeling this doesn't quite answer your question, however. :-)
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.ke
On Thu, 15 Sep 2016, Wade Berrier wrote:
> On Thu Sep 15 15:13, Alan Stern wrote:
> > On Sat, 10 Sep 2016, Wade Berrier wrote:
> >
> > > On Thu Aug 11 16:18, Alan Stern wrote:
> > > > I never received any replies to this message. Should the
an 32 ms.
Signed-off-by: Alan Stern
Tested-by: Wade Berrier
CC:
---
[as1812]
drivers/usb/core/config.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
Index: usb-4.x/drivers/usb/core/con
fo/?l=mythtv-users&m=144131333703197&w=2
You should a check for ep_out to the probe routine.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 10 Sep 2016, Wade Berrier wrote:
> On Thu Aug 11 16:18, Alan Stern wrote:
> > I never received any replies to this message. Should the patch I
> > suggested be merged?
> >
>
> Hello,
>
> I applied this updated patch to the fedora23 4.7.2 kernel and
On Sun, 21 Aug 2016, Matwey V. Kornilov wrote:
> In both cases (with or without HCD_BH), usb_hcd_giveback_urb is called
> every 0.01 sec. It is not clear why behavior is so different.
What behavior are you asking about? The difference between HCD_BH set
and not set?
Alan Stern
I never received any replies to this message. Should the patch I
suggested be merged?
Alan Stern
On Tue, 12 Jul 2016, Alan Stern wrote:
> On Sat, 9 Jul 2016, Mauro Carvalho Chehab wrote:
>
> > C/C linux-usb Mailing list:
> >
> >
> > Em Wed, 18 May 2016 0
-
> >
> > Is this change appropriate to be pushed upstream? Where to go from
> > here?
>
> This issue is at the USB core. So, it should be reported to the
> linux-usb mailing list.
>
> The people there should help about how to proceed to get this
> fi
rs to work queues when the long term goal is
> to use tasklets for URB completion anyway.
I'm not sure that this is a long-term goal for every HCD. For
instance, there probably isn't much incentive to convert a driver if
its host controllers can only run at low speed or full speed.
Alan
On Wed, 9 Sep 2015, Laurent Pinchart wrote:
> On Wednesday 09 September 2015 10:30:12 Hans de Goede wrote:
> > On 08-09-15 16:36, Alan Stern wrote:
> > > On Tue, 8 Sep 2015, Hans de Goede wrote:
> > >> On 09/07/2015 06:23 PM, Mian Yousaf Kaukab wrote:
> > >
On Wed, 9 Sep 2015, Hans de Goede wrote:
> Hi,
>
> On 08-09-15 16:36, Alan Stern wrote:
> > On Tue, 8 Sep 2015, Hans de Goede wrote:
> >
> >> Hi,
> >>
> >> On 09/07/2015 06:23 PM, Mian Yousaf Kaukab wrote:
> >>> urb completion callback
s this then
> still needed ?
We moved to handling URB completions in a tasklet, not a threaded
handler. (Similar idea, though.) And the change was made in only one
or two HCDs, not in all of them.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" i
ehci-platform: Use devm_of_phy_get_by_index
> usb: ohci-platform: Use devm_of_phy_get_by_index
For patches 3 and 4:
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
}
>
> + intf->dev.parent->power.force_direct_complete = true;
This seems wrong. The uvc driver is bound to intf, not to intf's
parent. So it would be okay for the driver to set
intf->dev.power.force_direct_complete, but it's wrong to set
intf->dev.parent-&g
ing list (CC-ed).
Alan Stern
> Jan 29 21:26:51 plattpcn kernel: [ 17.322493] input: UVC Camera (05ca:1812)
> as /devices/pci:00/:00:1d.7/usb2/2-4/2-4:1.0/input/input10
> Jan 29 21:26:51 plattpcn kernel: [ 17.322621] usbcore: registered new
> interface driver uvcvideo
ion. Notice that your _hcd_buffer_free still
dereferences hcd->driver; that will not point to anything useful if you
rmmod the HCD.
Also, you neglected to move the calls to hcd_buffer_destroy from
usb_remove_hcd to hcd_release.
On the whole, it would be easier if the UVC driver could release
On Mon, 14 Apr 2014, Ezequiel Garcia wrote:
> On Apr 14, Alan Stern wrote:
> > On Mon, 14 Apr 2014, Ezequiel Garcia wrote:
> >
> > > Currently stk1160_read_reg() uses a stack-allocated char to get the
> > > read control value. This is wrong because usb_control_
dition, we introduce a
> mutex to protect the value.
This isn't right either. The buffer must be allocated in its own cache
line; it must not be part of a larger structure.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a me
k1160_read_reg+0x52/0x80
> [5.705358] [] stk1160_i2c_busy_wait+0x6c/0x90
The bug is here. stk1160_i2c_busy_wait() passes the address of a
variable on the stack to stk1160_read_reg(), and that routine passes
the address to usb_control_msg(). But usb_control_msg() requires the
buffer to
ecause it uses a
> different urb->interval than EHCI.
You may be able to answer some of these questions by collecting usbmon
traces (see Documentation/usb/usbmon.txt). That would help pinpoint
sources of latency and tell you the actual URB intervals.
25 ms to avoid underruns seems prett
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
iver unbinds, correct?
Absolutely. When the next driver binds, it should get the default
values (i.e., the ones stored in the descriptors). This would be
analogous to the way we currently set each interface back to altsetting
0 when a driver unbinds.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
usting the streaming
> video resolution selected, right?
We haven't decided on the final API yet. However, note that
usb_alloc_urb() doesn't depend on the packet size. It requires you to
specify only the number of packets, not their sizes. Therefore it
doesn't matter whether you call us
o, then usb_change_ep_bandwidth() as a quirk, if bInterval
> or wMaxPacketSize were improperly filled.
>
> Right?
Or if the values are correct, but the driver wants to use something
different for its own reasons (for example, to get lower latency or
because it knows that it will never use pac
w
parameters applied to an endpoint in several altsettings, it will have
to change each altsetting separately.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 22 Sep 2013, Marc MERLIN wrote:
> On Sun, Sep 22, 2013 at 12:38:56PM -0400, Alan Stern wrote:
> > > gandalfthegreat:/sys/bus/usb/devices/3-1.6/power# grep . *
> > > active_duration:61227648
> > > async:enabled
> > > autosuspend:2
> > > au
nded_time:5324088
> runtime_usage:0
This all looks correct.
> Any ideas?
You might get more information from a kernel with CONFIG_USB_DEBUG
enabled. Especially if you add
#define VERBOSE_DEBUG
to drivers/usb/core/driver.c before the first #include line.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 18 Aug 2013, Geert Uytterhoeven wrote:
> On Thu, Jul 11, 2013 at 1:12 AM, Arnd Bergmann wrote:
> > On Wednesday 10 July 2013, Alan Stern wrote:
> >> This isn't right. There are USB host controllers that use PIO, not
> >> DMA. The HAS_DMA dependency shou
d file should be marked as
> const and __init and dropped after system initialization.
The phy_address things don't have to be defined or allocated in the
board file; they could be set up along with the platform data.
In any case, this was simply meant to be a suggestion to show that it
NULL, or an ERR_PTR otherwise.
> By the way, we need to consider other cases here as well, for example it
> would be nice to have a single phy_get() function that works for both non-
> DT and DT cases to make the consumer driver not have to worry whether it's
> being probed from DT or not.
You ought to be able to adapt this scheme to work with DT. Maybe by
having multiple "phy_address" arrays.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ata in PHY core comes from
> platform code.
You don't have to have a full definition in the board file. Just a
partial definition -- most of the contents can be filled in later, when
the PHY driver is ready to store the private data.
It's not a layering violation for one reg
nfo {
/* Info for the controller attached to this PHY */
struct controller_info *hinfo;
};
struct controller_info {
/* Info for the PHY which this controller is attached to */
struct phy_info *pinfo;
};
The board file for SoC A would contain:
struct phy_info phy1 =
ease indicate where I
> > have gone astray. Also, I'm not clear about the role played by various
> > APIs. For example, where does phy_create() fit into this picture?
>
> phy_create is the API by which the PHY's driver (the supplier) hook into the
> PHY framework. It's like the controller driver will always interact with the
> PHY driver through the PHY framework.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
some of the details above are wrong; please indicate where I
have gone astray. Also, I'm not clear about the role played by various
APIs. For example, where does phy_create() fit into this picture?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
n't know which PHY hardware
corresponded to a particular name.
Greg's suggestion is that you store the address of that data structure
in the platform data instead of storing the name string. Have the
consumer pass the data structure's address when it calls phy_create,
instead of
On Thu, 11 Jul 2013, Geert Uytterhoeven wrote:
> On Thu, Jul 11, 2013 at 3:01 AM, Alan Stern wrote:
> > On Thu, 11 Jul 2013, Arnd Bergmann wrote:
> >
> >> On Wednesday 10 July 2013, Alan Stern wrote:
> >> > This isn't right. There are USB host contr
On Thu, 11 Jul 2013, Arnd Bergmann wrote:
> On Wednesday 10 July 2013, Alan Stern wrote:
> > This isn't right. There are USB host controllers that use PIO, not
> > DMA. The HAS_DMA dependency should go with the controller driver, not
> > the USB core.
> >
>
. MOUSE_SYNAPTICS_I2C) already
> handle this in a similar way.
That seems reasonable.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I can try. Crazy
> ideas are welcome.
It's not a hack; it's a normal use for a quirk flag. Of course, if you
can figure out what's wrong with the camera and see how to fix it, that
would be best.
How does the camera perform on a Windows system after being put to
sleep and
er that if the HCD has
> enough buffering, there's no need for a pm_qos request.
The USB core is not PM-QOS aware. It relies on the PM core to tell it
when devices may safely be runtime-suspended.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media
rtly after the error message appears.
Alan Stern
P.S.: It will help if you unplug as many of the other USB devices as
possible before running this test.
Index: usb-3.6/drivers/usb/core/hcd.c
===
--- usb-3.6.orig/drivers/usb/core/h
On Mon, 22 Oct 2012, Daniel Mack wrote:
> On 22.10.2012 17:17, Alan Stern wrote:
> > On Sun, 21 Oct 2012, Artem S. Tashkinov wrote:
> >
> >> dmesg messages up to a crash can be seen here:
> >> https://bugzilla.kernel.org/attachment.cgi?id=84221
> >
>
On Sun, 21 Oct 2012, Artem S. Tashkinov wrote:
> dmesg messages up to a crash can be seen here:
> https://bugzilla.kernel.org/attachment.cgi?id=84221
The first problem in the log is endpoint list corruption. Here's a
debugging patch which should provide a little more information.
ci-hcd; none of them show xhci-hcd. Therefore the xHCI controller is
highly unlikely to be involved.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
oesn't have enough time to push error messages to rsyslog and fsync
> /var/log/messages
Is it possible to use netconsole? The screenshot above appears to be
the end of a long series of error messages, which isn't too useful.
The most important information is in the first error.
Al
y either a USB driver bug or video4linux driver bug:
Does the same thing happen with earlier kernel versions?
What about if you unload snd-usb-audio or ehci-hcd?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.k
callers
all seem to be okay in this respect, however I don't understand the
video drivers well enough to be certain about them.
Signed-off-by: Alan Stern
CC: Dmitry Torokhov
CC: Kyungmin Park
CC: Andy Walls
CC: Martin Schwidefsky
---
drivers/base/driver.c |
people. Removing them won't introduce any bugs that aren't
already present. There is no reason to keep them.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 26 Nov 2011, Johann Klammer wrote:
> Alan Stern wrote:
> > This is probably a low-level hardware error. Interference between the
> > two ports of some kind.
>
> This is quite possible. Have been able to produce a more verbose logfile
> snippet.
The log shows t
some kind.
> usbdump.mon: On request. usbmon output for the whole host controller
> during the event. I can mail this, but it's rather large and the mailing
> list won't accept the message.
Can you put the usbmon trace on a web server like pastebin.com?
Alan Stern
--
To unsubscribe
uess that what I'm trying to say here is, that if we are going to
> spend a significant amount of time on this, we might just as well
> go for the best solution we can come up with even if that is some
> more work.
Okay, go ahead. I have no objection.
Alan Stern
--
To unsubscribe from
.
No, I'm not going to Vancouver. However I will attend the Linux
Plumbers conference in Santa Rosa.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
dentical too.
I'm not against moving the whole thing into the kernel. I'm just
pointing out that an easier-to-code-up solution will accomplish much
the same result.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
gt; at the appropriate times must be a lot easier than porting the entire
> > driver into the kernel.
>
> Again, applications that won't implement this control will take the lock
> forever.
No, because there is no lock. Programs that haven't been changed will
continue to
re time, the program should be able to assume
the device's state hasn't changed.
I'm not claiming that this is a better solution than putting everything
in the kernel. Just that it is a workable alternative which would
involve a lot less coding.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
,
resets, and disconnects. Assuming usbfs is the only driver that will
want to share a device in this way, we could handle them.
Hans, what do you think?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 9 Aug 2011, Hans de Goede wrote:
> Hi,
>
> On 08/09/2011 04:19 PM, Alan Stern wrote:
> > On Tue, 9 Aug 2011, Hans de Goede wrote:
> > According to Theodore, we have developed 5 drivers for them because the
> > stillcam modes in different devices use fou
rent devices use four different vendor-specific
drivers. Does it really make sense to combine 5 drivers into one? I
think some sort of sharing protocol would work out better.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message
st ask
the program.
> Incidentally, I think that in some respects the fact that webcam support
> is in the kernel and stillcam support is in userspace is a red herring.
No, this has some significant implications. In particular, there's no
good way for the kernel driver to ask the userspace driver if it is
busy. If both drivers were in the kernel, this would be easy to
arrange.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 8 Aug 2011, Theodore Kilgore wrote:
> On Mon, 8 Aug 2011, Alan Stern wrote:
>
> > On Sun, 7 Aug 2011, Theodore Kilgore wrote:
> >
> > > This indirectly answers my question, above, about whatever device there
> > > may or may not be. What I get from t
at Hans was suggesting, today we have to merge
two separate drivers... then tomorrow we would have to merge two others
and then later on even more. Before you know it, we would end up with
a single gigantic kernel driver to manage every USB device! Obviously
not a sustainable approach in the long run.
and address
> 106
> [11080.688322] hub 1-0:1.0: unable to enumerate USB device on port 4
The dmesg log is relatively uninformative unless you enable
CONFIG_USB_DEBUG in the kernel build.
Have you tried running these tests on a different computer, preferably
one using a different chipset?
A
camera mode
> switching because that code could potentially get called on any in use USB
> device and if it does even thing like lsusb don't work correctly afterwards
> and completely unrelated devices don't work if they are later plugged into
> the
> same USB port.
Th
On Fri, 15 Jul 2011, Ming Lei wrote:
> Hi,
>
> On Fri, Jul 15, 2011 at 10:27 PM, Alan Stern
> wrote:
>
> > This is fine with me. �However, it is strange that the Set-Interface
> > request is necessary. �After being reset, the device should
> > automat
On Fri, 15 Jul 2011, Ming Lei wrote:
> Hi,
>
> On Thu, Jul 14, 2011 at 11:03 PM, Alan Stern
> wrote:
>
> > More likely, the reset erases some device setting that uvcvideo
> > installed while binding. �Evidently uvcvideo does not re-install the
> > setting duri
On Thu, 14 Jul 2011, Ming Lei wrote:
> Hi,
>
> On Wed, Jul 13, 2011 at 11:59 PM, Alan Stern
> wrote:
> > On Wed, 13 Jul 2011, Ming Lei wrote:
>
> >> Almost same.
> >
> > Come on. �"Almost same" means they are different. �That difference
On Wed, 13 Jul 2011, Ming Lei wrote:
> Hi,
>
> On Wed, Jul 13, 2011 at 11:20 PM, Alan Stern
> wrote:
>
> > Why should system suspend be different from runtime suspend? �Have you
>
> This is also my puzzle, :-)
>
> > compared usbmon traces for the tw
On Wed, 13 Jul 2011, Ming Lei wrote:
> Hi,
>
> On Tue, Jul 12, 2011 at 11:44 PM, Alan Stern
> wrote:
> > On Tue, 12 Jul 2011, Ming Lei wrote:
> >
> >> Hi Laurent,
> >>
> >> After resume from sleep, �all the ISO packets from camera are like
f880122d9d400 3527234708 C Zi:1:004:1 0:1:2600:0 32 0:0:12
> 0:1600:12 0:3200:12 0:4800:12 0:6400:12 51200 = 0c8c fa7e
> 012f1b05
>
> All are headed with 0c8c, see attached usbmon captures.
Maybe this device needs a USB_QUIRK_R
d never be less than 100 or
> > greater than 125.
>
> Ok. By the way, why should we limit it to be not less than 100?
> Likewise, a user who knows exactly what he/she is doing could limit
> periodic bandwidth to be less than 80% required by USB specification.
What's the poin
each microframe holds 7500 bytes (less if you count
bit-stuffing). 4% of that is 300 bytes, which is not enough for a
512-byte bulk packet. I think you'd run into trouble trying to do any
serious bulk transfers on such a tight schedule.
> Signed-off-by: Kirill Smelkov
> Cc
On Thu, 16 Jun 2011, Sarah Sharp wrote:
> On Thu, Jun 16, 2011 at 03:39:11PM -0400, Alan Stern wrote:
> > That's appropriate. But nobody should ever set an isochronous URB's
> > status field to -EPROTO, no matter whether the device is connected or
> > not
t take these events into account when
> > determining URB status codes.
>
> The xHCI driver will return -ESHUTDOWN as a status for URBs when the
> host controller is dying.
That's appropriate. But nobody should ever set an isochronous URB's
status field to -EPROTO, no ma
mean the device has been disconnected, not
-EPROTO. But usually HCD don't take these events into account when
determining URB status codes.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
hci-hcd and uhci-hcd is correct.
ohci-hcd behaves the same way too. And they all agree with the
behavior described in the kerneldoc for struct urb in
include/linux/usb.h.
> According to Documentation/usb/error-codes.txt, host controller drivers
> should
> set the status to -EXDEV.
r things like this and traditionally does resource
> management and things which come with that like refcounting: "unbind
> the driver from this device unless the device is currently in use".
Sure. At the moment the kernel does not keep track of whether a device
is currently in u
iver. You certainly wouldn't want to put it in V4L2.
> Or, to move the libgphoto2 driver to kernel, combine it in the same
> driver that handles streaming. No ?
No. Something else is needed.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 10 Jun 2011, Mauro Carvalho Chehab wrote:
> Em 10-06-2011 11:48, Alan Stern escreveu:
> > On Fri, 10 Jun 2011, Hans de Goede wrote:
> >
> >
> > As Felipe has mentioned, this sounds like the sort of problem that
> > can better be solved in userspace.
e the device back. I suggest using poll with POLLIN to signal this.
It seems as if you're trying to implement some notion of allowing a
device to have more than one driver at the same time. This is so far
out from the way the kernel behaves now, adopting it would be very
difficult if not impossible. Certainly the USB stack isn't the place
to start.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 13 Jun 2010, thomas schorpp wrote:
> Am 13.06.2010 15:57, schrieb Alan Stern:
> > On Sun, 13 Jun 2010, thomas schorpp wrote:
> >
> >> ehci-hcd is broken and halts silently or disconnects after hours or a few
> >> days, with the wlan usb adapter
> >
1 - 100 of 150 matches
Mail list logo
