Hello Stephen,
On Thu, 28 Apr 2005 14:17:35 -0700 (PDT) "Stephen J. Gowdy"
<[EMAIL PROTECTED]> wrote:
> The maintainer of that file is Martin Mares <[EMAIL PROTECTED]>. Here is the
> top
> of that file;
Great, thanks! I'll push the button.
Regard,
> #
> # List of PCI ID's
> #
> #
David Brownell wrote:
>On Thursday 28 April 2005 10:22 am, Brian Beardall wrote:
>
>
>>Brian Beardall wrote:
>>
>>
>>
>>>I've been experiencing IRQ don't cares using webcams that use
>>>isochronous transfers. ...
>>>
>>>
>>This is how the isochronous transfer is setup:
>>
>>urb->numbe
My kernel is 2.6.11
I added this patch:
[linux-usb-devel] S3C24XX USB controller Ben Dooks
when compile the kernel I found not ohci-s3c2410.o
created.
I known must modify the Makefile .
i don't known which one should edit .
and how to modify the Makefile!
please help me !!
thank you
On Thursday 28 April 2005 7:03 pm, Adam Oldham wrote:
> Resubmitting the URB like someone else suggested
> doesn't have any affect, that I can tell.
That would be because I said to _submit_ it with the
desired interval in the first place. Not *RE*submit.
The HCD asssigns the interval when it sc
--- Alan Stern <[EMAIL PROTECTED]> wrote:
> On Thu, 28 Apr 2005, Adam Oldham wrote:
> >
> > I have a USB device that has 1 configuration and
> has
> > an interrupt endpoint set up as:
> > Endpoint:
> > bLength =7
> > bDescriptorType = 05
> > bEndpointAdd
On Fri, 29 Apr 2005, Oliver Neukum wrote:
> > "Provided that you know when you can safely autosuspend." If the driver
> > doesn't know when it can suspend its device, who else would know?
>
> Those who understand the semantics, which with scsi (sg) might be
> in user space.
Definitely we would
This adds so-called "HX" with a backport from 2.6. We ship this with RHEL 3,
so I thought I would post it for great justice, in case someone needs it.
The failure symptom is that adapter gets recognized fine, receive works fine,
but transmit doesn't.
diff -urp -X dontdiff linux-2.4.31-pre1/drivers
Greg KH <[EMAIL PROTECTED]> wrote:
>
> > It's a bit of a hassle that your patches aren't based on latest -linus.
>
> I understand. That will change, once the -git nightly snapshots start
> up.
It's at http://www.zip.com.au/~akpm/linux/patches/stuff/linus.patch.gz
I'll update that a few times a
On Friday 22 April 2005 7:39 pm, Glenn Maynard wrote:
> > I think the "greedy" approach is probably best.
>
> Based on David's explanation, yes; I'll have it choose the highest-power
> configuration <= 100mA, or the lowest power configuration if none fit.
> (I have one pen drive, a 128mb Attache,
On Tuesday 26 April 2005 1:57 am, Eugeny S. Mints wrote:
> --- pxa2xx_udc.c.orig 2005-04-26 12:31:49.0 +0400
> +++ pxa2xx_udc.c2005-04-26 12:32:26.0 +0400
Looks fine to me, except that patches should be applicable at the top
level with "patch -p1" ...
> @@ -970,7 +970,8
On Thu, Apr 28, 2005 at 04:31:21PM -0700, Andrew Morton wrote:
> Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Apr 28, 2005 at 03:34:14PM -0700, Greg KH wrote:
> > > Examples of the output of this script can be seen at:
> > > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
>
Greg KH <[EMAIL PROTECTED]> wrote:
>
> On Thu, Apr 28, 2005 at 03:34:14PM -0700, Greg KH wrote:
> > Examples of the output of this script can be seen at:
> > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
>
> Andrew, I'm now putting my broken out patches in this directory so
On Fri, 2005-04-22 at 09:21 +0200, Lothar Wassmann wrote:
> What type of memory access do you use? I'm using VLIO with the MSC
> setting 0x7f8c at 99.53MHz memclk. This is probably the only setup
> that can guarantee the chips timing requirements.
>
> Be aware that VLIO uses nPWE instead of nWE as
On Thu, Apr 28, 2005 at 03:34:14PM -0700, Greg KH wrote:
> Examples of the output of this script can be seen at:
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
Andrew, I'm now putting my broken out patches in this directory so you
can apply them to the -mm tree. You can
Kernel Developer's guide to using quilt so everyone else benefits.
Note, this is just one way to do this, if you have a different process
for dealing with patches and making them public for others to view and
test, by all means, please do it. I'm offering this up as one
possible way to ac
> Oliver, I don't understand your point. Which devices and drivers are you
> referring to?
Scsi and drivers that drive scsi cards or their equivalent.
> "Provided that you know when you can safely autosuspend." If the driver
> doesn't know when it can suspend its device, who else would know
On Thu, 28 Apr 2005, Oliver Neukum wrote:
> > > Please consider scsi. It has no idea about what is going on.
> >
> > In principle this shouldn't matter. If a device is autosuspended then it
> > should autoresume whenever a new request (such as a new SCSI command)
> > arrives.
>
> Provided tha
Am Donnerstag, 28. April 2005 23:14 schrieb David Brownell:
> On Thursday 28 April 2005 2:01 pm, Oliver Neukum wrote:
> > Am Donnerstag, 28. April 2005 17:40 schrieb David Brownell:
> > > On Thursday 28 April 2005 12:13 am, Oliver Neukum wrote:
> > > >
> > > > Please consider scsi. It has no idea
The maintainer of that file is Martin Mares <[EMAIL PROTECTED]>. Here is the top
of that file;
#
# List of PCI ID's
#
# Maintained by Martin Mares <[EMAIL PROTECTED]> and other volunteers from
the
# Linux PCI ID's Project at http://pciids.sf.net/. New data are
always
# welc
On Thursday 28 April 2005 2:01 pm, Oliver Neukum wrote:
> Am Donnerstag, 28. April 2005 17:40 schrieb David Brownell:
> > On Thursday 28 April 2005 12:13 am, Oliver Neukum wrote:
> > >
> > > Please consider scsi. It has no idea about what is going on.
> >
> > No more than for example an IDE disk
Am Donnerstag, 28. April 2005 22:29 schrieb Roberto Roccatello:
> Hi
> I'm trying to get this "U.S. Robotics 56K Faxmodem USB" working
> with cdc-acm driver but with no results.
> I would like to know what do you think about this output:
>
> [EMAIL PROTECTED]:~$ tail -f /var/log/messages
> usb 1-1
On Thu, 28 Apr 2005, Adam Oldham wrote:
> Hi all,
>
> I am really banging my head against a wall with a
> problem.
>
> I have a USB device that has 1 configuration and has
> an interrupt endpoint set up as:
> Endpoint:
> bLength =7
> bDescriptorType = 05
>
Am Donnerstag, 28. April 2005 17:40 schrieb David Brownell:
> On Thursday 28 April 2005 12:13 am, Oliver Neukum wrote:
> >
> > Please consider scsi. It has no idea about what is going on.
>
> No more than for example an IDE disk does. Yet somehow
> "hdparm -S" lets the drives themselves spin dow
On Thursday 28 April 2005 1:54 pm, Alan Stern wrote:
> I wasn't sure how to handle this in the EHCI driver. It looks like the
> driver assumes power was _always_ lost unless it sees a suspended port
> after the resume. Is that how it's supposed to work?
That's what it does for now. There was
Am Donnerstag, 28. April 2005 17:24 schrieb Alan Stern:
> On Thu, 28 Apr 2005, Oliver Neukum wrote:
>
> > Am Donnerstag, 28. April 2005 02:26 schrieb David Brownell:
> > > On Wednesday 27 April 2005 2:32 pm, Alan Stern wrote:
> > > >
> > > > That's not in question. The issue is: Out of all the d
On Thursday 28 April 2005 1:08 pm, Adam Oldham wrote:
> I would like to change the bInterval value to ff to
> change the poll interval.
Just submit your URB with the desired poll interval;
don't bother trying to change the device's config
descriptor(s), treat that as read-only.
--
David:
Here's my new usb_root_hub_lost_power() routine. This is actually two
separate patches pasted together; the first one updates usbcore and the
second contains the changes for OHCI and UHCI (with a couple of unrelated
modifications thrown in too).
I wasn't sure how to handle this in the E
This goes on top of the other OMAP driver update you already have.
DMA updates include one small bugfix and some peformance updates.
Please merge.
- Dave
More omap_udc updates:
* OMAP 1710 updates
- new UDC bit for clearing endpoint toggle, affecting CLEAR_HALT
- new OTG bits affect
Again a net code shrink (including removing #ifdeffery); please merge.
- Dave
Some cleanup for the the Ethernet part of the Ethernet/RNDIS gadget driver:
- Remove remnants of ancient endpoint init logic; this is simpler, clearer
- Save a smidgeon of space in the object file
- Get rid of s
This boils down to a code shrink and some minor fixes.
Please merge.
- Dave
Some bugfixes and lots of cleanup (net code shrink):
- On reset, force the RNDIS state machine its initial state
- Hook up the RNDIS (outgoing) filters to the CDC mechanism
- Lots of cleanup:
* Eliminate dupl
On Thursday 28 April 2005 1:07 pm, Michael wrote:
>
>
> As far as the "missing status stage", this still happens, but it
> runs okay. This warning happens for the get descriptors for the
> lang IDs, the iProduct, iManufacturer, and iSerialNumber data. I'm
> assuming it's a more general USB thin
Hi
I'm trying to get this "U.S. Robotics 56K Faxmodem USB" working
with cdc-acm driver but with no results.
I would like to know what do you think about this output:
[EMAIL PROTECTED]:~$ tail -f /var/log/messages
usb 1-1: new full speed USB device using uhci_hcd and address 2
drivers/usb/class/cdc
Hi,
> So, we're handling all of the interrupts fine, but every time we
> handle an ATL interrupt, it says that it's not handled, and we get
> the "nobody cared" message.
>
Oops. I wonder, why I did never get one of those...
> Thanks for your feedback and insight. It sure helped me find this
> p
> > No, I suppose I don't have a special reason. I'm running my
> > kernel without any modules at all, so I was sticking to that.
> > I have it automated to be easy enough to boot with a new
> > kernel. (As easy as transferring a new module over and trying
> > it out).
> >
> I'm running my test
Hi all,
I am really banging my head against a wall with a
problem.
I have a USB device that has 1 configuration and has
an interrupt endpoint set up as:
Endpoint:
bLength =7
bDescriptorType = 05
bEndpointAddress= 83 (in)
bmAttributes
Hello, this is the output I get with dmesg when I plug in my audigy 2 nx
usb:
(it doesn't sound anything. One month ago it worked but now it doesn't
sound anything, and I can't
find what happen)
/usb 2-2: new full speed USB device using address 2
usbaudio: device 2 audiocontrol interface 0 has 1
Hello Stephen,
On Thu, 28 Apr 2005 10:00:46 -0700 (PDT) "Stephen J. Gowdy"
<[EMAIL PROTECTED]> wrote:
> That means there is no entry in the pci.ids file for those devices. That
> is only used for this output I believe (lspci).
I see. I just wanted to report those hardware IDs, in case it is use
On Thu, Mar 17, 2005 at 04:40:15PM +0100, Florian Echtler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello everyone,
>
> after the idmouse driver is now in the mainline kernel, we received
> some feedback that allowed us to improve the driver a bit.
>
> Changes:
> - - added the
On Mon, Apr 25, 2005 at 09:46:29PM -0700, Matthew Dharm wrote:
> Here is patch md.git001 -- it's my first patch submission from a GIT
> archive. Now that we have diff-tree-helper, things are much better...
>
> There's probably a better way to do this, but until I get a hold of more
> people's sup
On Mon, Apr 25, 2005 at 11:29:50AM -0400, Alan Stern wrote:
> Greg:
>
> This patch adds a reboot notifier to uhci-hcd so that it can quiesce the
> controller hardware during a reboot. This is mainly to benefit programs
> like kexec, which expect the hardware to be idle, not doing DMA or
> gene
Greg:
After all the discussion you might not be interested in this still, but
nevertheless here it is. This patch adds a shutdown method to the
uhci-hcd driver. Its prerequisite is the patch you wrote adding shutdown
support for PCI.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]
Roman, Pat:
Here is a fix for driver_detach(). It's a little ugly because it avoids
using the klist iterator, but there's no way around it -- the iterator
simply can't be made to work here. Not only does it prevent
device_release_driver() from calling klist_remove(), but also it prevents
doing g
This report relates to a message you sent with the following header fields:
Message-id: <[EMAIL PROTECTED]>
Date: Thu, 28 Apr 2005 23:51:22 +0530
From: linux-usb-devel@lists.sourceforge.net
To: [EMAIL PROTECTED]
Subject:
Your message cannot be delivered to the following recipients:
R
On Thu, Apr 21, 2005 at 05:12:59PM +0300, Olav Kongas wrote:
> Greg,
>
> This patch fixes an oops triggered at rmmod of isp116x-hcd
> after the probe() has failed.
>
> Also, it extends the error message printed, if the driver
> cannot detect "Chip's Clock Ready" after a software reset.
> As Ia
On Thursday 28 April 2005 10:22 am, Brian Beardall wrote:
> Brian Beardall wrote:
>
> >I've been experiencing IRQ don't cares using webcams that use
> >isochronous transfers. ...
>
> This is how the isochronous transfer is setup:
>
> urb->number_of_packets = 10;
> urb->intervral = 1;
> urb->tran
Brian Beardall wrote:
>I've been experiencing IRQ don't cares using webcams that use
>isochronous transfers. These are reproducible on different
>mainboards. The one is an MSI-6195, and the other is a MSI-6167. The
>bottom two kernel logs occured after usb debugging was enabled. I am
>not qui
That means there is no entry in the pci.ids file for those devices. That
is only used for this output I believe (lspci).
On Thu, 28 Apr 2005, wwp wrote:
> Hello there,
>
>
> dunno if that helps or if it's the wrong place for this.. I'm running a 2.6.11
> kernel on a Dell Latitude D810 (FC3+upgrad
Hello there,
dunno if that helps or if it's the wrong place for this.. I'm running a 2.6.11
kernel on a Dell Latitude D810 (FC3+upgrades). lspci reports unknown Dell USB
devices IDs (but everything works well).
Maybe someone would found interesting to get the USB devices IDs from the
output belo
Hi Michael,
> No, I suppose I don't have a special reason. I'm running my kernel
> without any modules at all, so I was sticking to that. I have it
> automated to be easy enough to boot with a new kernel. (As easy as
> transferring a new module over and trying it out).
>
I'm running my test sys
--- Lothar Wassmann <[EMAIL PROTECTED]> wrote:
> Hi Michael,
>
> Michael writes:
> > I would disagree. I added a printk at the top of the
> > isp1362_irq function, as you can see in the bootup messages.
> > However, it doesn't show up with the "nobody cared" messages.
> > Perhaps this is a hin
Duncan Sands wrote:
>>To follow up on my findings, I just noticed that the call to
>>usb_unlink_urb() returns -EINPROGRESS.
>>
>>
>
>With this extra info everything seems clear. I will try to
>do something about it tomorrow.
>
>
Excellent.
Please let me know if there is any extra informat
On Thursday 28 April 2005 12:13 am, Oliver Neukum wrote:
>
> Please consider scsi. It has no idea about what is going on.
No more than for example an IDE disk does. Yet somehow
"hdparm -S" lets the drives themselves spin down when
they're idle for a while ... a kind of autosuspend.
--
I just found out about these Linux drivers ... likely of interest
if you're working with USB OTG designs from Mentor Graphics:
http://www.mentor.com/products/ip/usb/usb20otg/usb-otg-driver.cfm
The drivers are GPL'd, and presumably can be made to work with the
FPGA devel cards as well as SOC chi
On Thu, 28 Apr 2005, Oliver Neukum wrote:
> Am Donnerstag, 28. April 2005 02:26 schrieb David Brownell:
> > On Wednesday 27 April 2005 2:32 pm, Alan Stern wrote:
> > >
> > > That's not in question. The issue is: Out of all the drivers floating
> > > around, which one should decide when a partic
On Thu, 28 Apr 2005, Shiju Mathew wrote:
> Hi Alan,
> I stop hald deamon and plugged in the usb cable and then started the
> deamon. But with the same result as before. The same error messages
> and the keystrocks and mouse movements are not recognized. I also
> booted the system with the usb cabl
On Wed, 27 Apr 2005, David Brownell wrote:
> On Wednesday 27 April 2005 2:32 pm, Alan Stern wrote:
> >
> > That's not in question. The issue is: Out of all the drivers floating
> > around, which one should decide when a particular device can be suspended
> > for lack of activity?
>
> Erm, not
On Thursday 28 April 2005 12:36 am, [EMAIL PROTECTED] wrote:
> I wonder if two computers both using Red Hat Linux
> can communicate with USB network link cable.
> If can,how to send data and receive data.
http://www.linux-usb.org/usbnet/
Hallo,
I installed Gentoo an want to get the hauppauge dec3000s working.
(i also tried with a few other distributions)
i am using a toshiba satellite p20.
The drivers are build into the kernel.
when i connect the box i got this in dmesg:
Apr 26 07:28:37 localhost wait_for_sysfs[27603]: either
On Wed, 2005-04-27 at 16:21 -0400, David Zeuthen wrote:
> it seems that recent kernels (I'm using the Fedora 2.6.11-1.1268_FC4
> kernel which I believe is based off 2.6.12-rc3 and AFAIK it doesn't have
> any invasive patches in that area) has changed behavior wrt hotplug
> event ordering. In [1], I
Hello,
I am Chen Xiaolong from China.
I like Red Hat Linux.
I am preparing a project solution.
I wonder if two computers both using Red Hat Linux
can communicate with USB network link cable.
If can,how to send data and receive data.
Thank you!I wait for your answer.
___
Am Donnerstag, 28. April 2005 02:26 schrieb David Brownell:
> On Wednesday 27 April 2005 2:32 pm, Alan Stern wrote:
> >
> > That's not in question. The issue is: Out of all the drivers floating
> > around, which one should decide when a particular device can be suspended
> > for lack of activit
61 matches
Mail list logo
