On 07/24/2012 10:02 AM, Laurent Pinchart wrote:
> Hi Adam,
>
> On Monday 23 July 2012 16:26:16 Adam Wozniak wrote:
>> I'm trying to control the "recording" light on a Logitech C270 webcam
>> from a linux userspace app.
>>
>> There is a windows app that does this, so I know it is possible.
>>
>> Ru
On 2012/12/14 23:44, Alan Stern wrote:
On Fri, 14 Dec 2012, Lan Tianyu wrote:
Hi Alan:
debounce is still needed. If connect status was not stable, resume
operation will fail. So how about following?
Actually, I'm not sure that a debounce is needed.
Debouncing is used when a plug is p
On Sun, 16 Dec 2012, Lan Tianyu wrote:
> On 2012/12/14 23:44, Alan Stern wrote:
> > On Fri, 14 Dec 2012, Lan Tianyu wrote:
> >
> >> Hi Alan:
> >>debounce is still needed. If connect status was not stable, resume
> >> operation will fail. So how about following?
> >
> > Actually, I'm not sure t
Am 14.12.2012 23:02, schrieb Alan Stern:
> On Thu, 13 Dec 2012, Frank Schäfer wrote:
>
>> I have the MCP61 (rev. A2) with id 10de:03f1.
>>
>> Further NVIDIA OHCI HCD IDs can be found at
>> http://openbenchmarking.org/linux/PCI/0c03.
>> But I'm not sure that we should blacklist them all. Maybe this
Hi Alan,
I applied the modifications you suggested, this is the output:
[ 110.922009] ehci_hcd :00:0b.1: async off
[ 209.362134] ehci_hcd :00:0b.1: async on
[ 241.794760] ehci_hcd :00:0b.1: alan start cur time 4294908992 last scan
4294878606
[ 241.794774] ehci_hcd :00:0b.1:
Hi.
I have a device which enumerates properly on this superspeed host controler:
06:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller
(rev 01)
but triggers several warnings from the xhci_hcd module, and ultimately fails
activating the default configuration:
usb 1-1: new
This is, I think, a webcam built into the Samsung 350V model
NP350E7C-A05UK. I can't see it in windoze 8's pathetic excuse for a
'control panel' or the latest usb.ids. I Imagine 2232 is registered
somewhere as a manufacturer but I've no hint who made it. If it's not
the webcam, it's probably an sd
Le dimanche 16 décembre 2012 20:46:38, Vincent Pelletier a écrit :
> I have a device which enumerates properly on this superspeed host
> controler:
And I forgot to mention:
- running vanilla kernel 3.6.10
- The original issue which had me look into this is my libusb1.0-base
userspace driver[1] f
On Thu, 13 Dec 2012 20:22:26 +0530, Vivek Gautam
wrote:
> Using chip specific compatible string as it should be.
> So fixing this for ehci-s5p, ohci-exynos and dwc3-exynos
> which till now used a generic 'exynos' in their compatible strings.
>
> This goes as per the discussion happened in the th
On Thu, 13 Dec 2012 22:06:01 +0530, Vivek Gautam
wrote:
> Adding EHCI device tree node for Exynos5250 along with
> the device base adress and gpio line for vbus.
>
> Signed-off-by: Vivek Gautam
> Acked-by: Jingoo Han
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 25
> +++
Le dimanche 16 décembre 2012 20:46:38, Vincent Pelletier a écrit :
> I checked the specs, and the warnings about wMaxPacketSize seem
> justified (although it's unclear to me wether wMaxPacketSize is
> restricted to exactly 512B in HS, or only upper-bound at 512B).
Another reply to myself:
Tested U
On Sun, 16 Dec 2012, Vincent Pelletier wrote:
> Hi.
>
> I have a device which enumerates properly on this superspeed host controler:
>
> 06:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller
> (rev 01)
>
> but triggers several warnings from the xhci_hcd module, and ultim
于 2012年12月16日 00:58, Alan Stern 写道:
> In my opinion this problem is not serious enough to spend much time on,
> and I have lots of other, more important things, to do. If you want to
> fix it, go ahead and send in a patch.
>
> Alan Stern
ok, I will send the relative patch (although I do not
于 2012年12月16日 01:04, Alan Stern 写道:
> On Sat, 15 Dec 2012, Chen Gang wrote:
>
>> > Hello Alan Stern:
>> >
>> > in drivers/usb/host/ohci-q.c, function finish_urb:
>> > when we finish call urb_free_priv, we not set urb->hcpriv = NULL (line
>> > 46)
>> > urb_free_priv call kfree for urb_p
于 2012年12月17日 09:37, Chen Gang 写道:
> 于 2012年12月16日 01:04, Alan Stern 写道:
>> Also, don't forget that the first think usb_hcd_giveback_urb does is
>> set urb->hcpriv to NULL.
>>
>
> in finish_urb:
> when call usb_hcd_giveback_urb, need unlock firstly (lock again, after
> finish).
> kfree
On Mon, 17 Dec 2012, Chen Gang wrote:
> are all kfree for urb->hcpriv in lock protected ?
Yes. The only one is in urb_free_priv, and it is always called with
the lock held.
> (set urb->hcpriv = NULL in usb_hcd_giveback_urb, not in lock protected).
> can you be sure that it is no
于 2012年12月17日 11:08, Alan Stern 写道:
> It is pretty much as I explained in my previous email.
>
> finish_urb calls usb_free_priv while holding the lock. Then while
> still holding the lock, it calls usb_hcd_unlink_urb_from_ep.
>
> In addition, ohci_urb_dequeue calls usb_hcd_check_unlink_urb whil
17 matches
Mail list logo
