Hello List
I have ported linux 2.6.12 usb driver to our custom platform consisting of a
mips processor. The mips processor has a in-core usb 2.0 host controller
which supports ehci and ohci.The operational registers for ehci and ohci
are at certain set locations in the core. I used the platform
On Mon, 3 Oct 2005, Christopher Li wrote:
> I did that already, namely using the disconnect ioctl.
> There is a catch as well, that ioctl can't pass the 32 to 64 compat
> layer, so it will not work on 64 bit linux host when the app is 32 bit.
>
> I try to fix that in my local kernel, and I realiz
Greg:
This patch (as574) updates the PCI BIOS usb-handoff code for UHCI
controllers, making it work like the reset routines in uhci-hcd. This
allows uhci-hcd to drop its own routines in favor of the new ones
(code-sharing).
Once the patch is merged we can turn the usb-handoff option on
permanent
I did that already, namely using the disconnect ioctl.
There is a catch as well, that ioctl can't pass the 32 to 64 compat
layer, so it will not work on 64 bit linux host when the app is 32 bit.
I try to fix that in my local kernel, and I realize that there is
a million choice to abuse the USBDEVF
On Mon, 3 Oct 2005, Christopher Li wrote:
> Yes, we still need a device level locking protecting. For the user process
> and kernel driver as well.
>
> The set interface is a good example that interface don't exist as a stand
> alone
> entity. Similar things with reset devices.
>
> So until t
On Mon, Oct 03, 2005 at 10:32:19AM -0400, Alan Stern wrote:
> On Sat, 1 Oct 2005, Christopher Li wrote:
>
> It's not a matter of interfering. The problem is that whenever anyone
> does a Set-Configuration, _all_ the current interfaces go away and new
> ones are created. Hence the drivers curre
Hi Greg,
I'm facing two problems regarding power ON/OFF problem which are
mentioned below:
Case 1:
I'm using RHEL4 with usbserial driver for my application and here I'm
facing problem while doing power ON/OFF problem. It works fine upto 10
times after that I'm getting problem in usb_dump_endpo
Pat LaVarre <[EMAIL PROTECTED]> writes:
P: Vendor=10d6 ProdID=1100 Rev= 1.00
...
P: Vendor=054c ProdID=019d Rev= 1.00
>>>
>>> These appear to be instances of USB idProduct: idVendor: bcdDevice
>>>
>>
>> I didn't follow what you meant. Please explain.
>
> I can explain better
On Sat, 1 Oct 2005, Christopher Li wrote:
> Hi,
>
> I notices in the recent kernel that set config from usbdevfs
> can fail with -EBUSY.
>
> /* Don't touch the device if any interfaces are claimed.
>* It could interfere with other drivers' operations, and if
>* an interface
I include the entry to one usb flash disk that had problem here. I
think is really good to include it on 2.6.14 since its very
trivial
and worked fine here.
I'm not a big fan of doing the entire - range unless you
have
some idea that lots of devices in the range are affected.
I
Pat LaVarre <[EMAIL PROTECTED]> writes:
I include the entry to one usb flash disk that had problem here. I
think is really good to include it on 2.6.14 since its very trivial
and worked fine here.
>>>
>>> I'm not a big fan of doing the entire - range unless you have
>>> some
On Tue, Sep 20, 2005 at 02:00:51PM -0700, Pete Zaitcev wrote:
> This code appears to be more trouble than it's worth, considering that
> no normal users reload drivers. So, we comment it for now. It is not
> removed outright for the benefit of hackers (that is, myself).
My scripts reload drivers d
12 matches
Mail list logo
