Hi Greg! Hi lists!
On Don, 15 Apr 2004, Greg KH wrote:
> How about the 2.6.6-rc1 kernel? Are you using a uhci or ohci
> controller?
With 2.6.6-rc1 it is NOT working anymore.
I have both usb_uhci and usb_ohci/ehci. The internal usb controller
where the palm is connected is usb_uhci, additionally
I'm working on support for a chip which handles EP0 trafic almost
completely in hardware (Hynix H7202). As you don't get things like Set
Configuration Requests the usual state machines do not work, so I fake
the calls from the reset interrupt.
That means that I have to call dev->driver->setup() f
On Thu, Apr 15, 2004 at 10:24:05PM +0200, Wolfgang Mües wrote:
> 0x12345 is outside of the unsigned 16 bit range. It can't work...
Ok - must have been a late night brain segfault ;) But it happens
identically when you use values larger than 0x7FFF.
Robert
--
Dipl.-Ing. Robert Schwebel | http:
BANNED FILENAME ALERT
Our content checker found
banned name: message.scr
in email presumably from you (<[EMAIL PROTECTED]>), to the following recipient:
-> [EMAIL PROTECTED]
Delivery of the email was stopped!
The message has been blocked because it contains a component
(as a MIME part or nes
On Thu, 2004-04-15 at 18:16, David Brownell wrote:
> Kari Veneranta wrote:
>
> > // Function Configuration Descriptor
> > DESCRIPTOR FConf_desc[L_F_CONFIG] PROGMEM =
> > {
>
> Looks like your driver's configuration descriptor isn't being
> delivered as you expect. For example, the wTotalLength o
ACADEMIA WALL STREET FITNESS
Fone: 3335-7227 3291-6590
Clientes
e funcionários das empresas abaixo.
Pagam
apenas R$ 58,00 para fazer ginástica e musculação todos os dias horários livres e R$
70.00 para spinning, ginástica e
musculação.
TELEMIG
CELULAR - TIM MAXITEL
On Fri, 16 Apr 2004 00:35:16 +0100
Martin Habets <[EMAIL PROTECTED]> wrote:
> There is a problem in the GET_DEVICE_ID ioctl() implementation. The patch below
> (against 2.6 current) fixes the code to be according to the official usb printer
> spec.
>[...]
I was told Vojtech Pavlik owns usblp in
Greg KH wrote:
On Thu, Apr 15, 2004 at 10:10:00AM -0400, Alan Stern wrote:
Greg:
I just noticed your new usb_get/put_intf() functions. Creating them is a
tacit admission that drivers will need to continue using interfaces after
their disconnect() routine has returned. Is this wise?
Sysfs may
There is a problem in the GET_DEVICE_ID ioctl() implementation. The patch below
(against 2.6 current) fixes the code to be according to the official usb printer spec.
Most printers are not affected by this fix, as they use interface 0 and alternate 0.
For those, nothing changes. But my printer/sca
On Thu, 15 Apr 2004, Simone Gotti wrote:
> > When that happens, copy the file /proc/driver/uhci/:00:10.1 and post
> > the contents. Also, first make sure that you load the UHCI driver with
> >
> > modprobe uhci-hcd debug=3
> >
>
> I've did this 4 time with the same results, I've
> used
On Thu, 15 Apr 2004, Oliver Neukum wrote:
> Am Donnerstag, 15. April 2004 22:51 schrieb [EMAIL PROTECTED]:
> > I am doing a usb project and I am interested in the device enumeration
> > process. Where is the enum process carried out? I have been to umpteen
> > Linux usb related sites and so far co
On Thu, Apr 15, 2004 at 01:35:15AM -0700, Andrew Morton wrote:
>
> (cc linux-usb-devel)
>
> Norbert Preining <[EMAIL PROTECTED]> wrote:
> >
> > Hi USB developers!
> >
> > Hopefully you can help tracking down the following problem:
> >
> > I am using the -mm series of linux kernels which include
Am Donnerstag, 15. April 2004 22:51 schrieb [EMAIL PROTECTED]:
> I am doing a usb project and I am interested in the device enumeration
> process. Where is the enum process carried out? I have been to umpteen
> Linux usb related sites and so far come up dry. Is it in a kernel module or
> something
On Thursday 15 April 2004 22:59, Greg KH wrote:
> On Thu, Apr 15, 2004 at 12:07:55PM +0200, Simone Gotti wrote:
> > after applying :
> > 01-Do short packet detection correctly => Bluetooth dongle OK
> > 02-Improved handling of short control transfers => Bluetooth device
> > DOESN'T WORK ANYMORE!
>
On Thu, Apr 15, 2004 at 10:10:00AM -0400, Alan Stern wrote:
> Greg:
>
> I just noticed your new usb_get/put_intf() functions. Creating them is a
> tacit admission that drivers will need to continue using interfaces after
> their disconnect() routine has returned. Is this wise?
>
> The current
On Thu, Apr 15, 2004 at 12:07:55PM +0200, Simone Gotti wrote:
> after applying :
> 01-Do short packet detection correctly => Bluetooth dongle OK
> 02-Improved handling of short control transfers => Bluetooth device DOESN'T
> WORK ANYMORE!
Did you apply the patches from the Bluetooth developers t
On Thursday 15 April 2004 20:58, Alan Stern wrote:
>
> It is a big help.
>
> What happens when all the patches are applied and you try to use the
> Bluetooth device? Does it just stop doing anything and give timeouts?
I've applied the four patches and I've got the same problems, the same that I
I am doing a usb project and I am interested in the device enumeration process. Where
is the enum process carried out? I have been to umpteen Linux usb related sites and so
far come up dry. Is it in a kernel module or something in the file system? I'm lost.
Thanks.
Dave
--
On Thu, 15 Apr 2004, Robert Schwebel wrote:
> On Thu, Apr 15, 2004 at 02:51:18PM -0400, Alan Stern wrote:
> > For Linux 2.6 you could use module_param instead of MODULE_PARM. That
> > will allow you to specify the type as ushort.
>
> Ah, ok. Hmm, strange - I tried this but, although modinfo say
On Thu, 15 Apr 2004, Colin Leroy wrote:
> Like this one? It works. I'm a bit wondering, however, how comes
> usb_interface_claimed() returns true, and the check in
> usb_driver_claim_interface() passes?
While an interface is being probed, usb_interface_claimed() will always
return true for it.
Hello Robert,
On Thursday 15 April 2004 21:09, Robert Schwebel wrote:
> On Thu, Apr 15, 2004 at 11:48:14AM -0700, Pete Zaitcev wrote:
> > What is the symptom of "do not work"?
>
> The driver returns -1 and does not load. You can try by calling it
> with for example vendor=0x1234 product=0x12345.
Hi Colin,
That test has always been buggy -- better to just remove it. For
that matter, usb_interface_claimed() calls should all vanish ... it's
better to fail if claiming the interface fails (one step, not two).
Care to try an updated patch?
Like this one? It works. I'm a bit wondering, howeve
On Thu, Apr 15, 2004 at 02:51:18PM -0400, Alan Stern wrote:
> For Linux 2.6 you could use module_param instead of MODULE_PARM. That
> will allow you to specify the type as ushort.
Ah, ok. Hmm, strange - I tried this but, although modinfo says that
there is a vendor and product parameter, I get t
On 15 Apr 2004 at 11h04, David Brownell wrote:
Hi David,
> That test has always been buggy -- better to just remove it. For
> that matter, usb_interface_claimed() calls should all vanish ... it's
> better to fail if claiming the interface fails (one step, not two).
> Care to try an updated patc
On Thu, Apr 15, 2004 at 11:48:14AM -0700, Pete Zaitcev wrote:
> What is the symptom of "do not work"?
The driver returns -1 and does not load. You can try by calling it with
for example vendor=0x1234 product=0x12345.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix
On Thu, 15 Apr 2004, Simone Gotti wrote:
> Hi to All.
>
> Finally I've found the patch that caused my bluetooth device to don't work
> anymore.
>
> I've applied the patch sent by Greg KH to Linus yesterday in these order (to
> make them apply correctly):
>
> 01-Do short packet detection corre
Colin Leroy wrote:
Hi,
I gave 2.6.6-rc1 a try, and found that cdc-acm is now broken is a new way:
... usb_interface_claimed() returns true ... intf->dev.driver is already cdc-acm
The interface being probed is by definition not going to be claimed
by any other driver ... it shouldn't check or clai
On Thu, 15 Apr 2004, Robert Schwebel wrote:
> Hi,
>
> the usbserial driver can have two parameters, vendor=0x and
> product=0x. Currently they are defined as 'h' which is 16 bit
> (correct), but _signed_. This means that IDs larger than 0x7FFF do not
> work right now.
>
> The fix below
Am Donnerstag, 15. April 2004 20:11 schrieb Colin Leroy:
> Hi,
>
> cdc-acm was broken since after 2.6.4, due to the alt_cursetting changes. I
> sent a patch, which has been integrated (well, the same one has ;-)) not
> long ago. I gave 2.6.6-rc1 a try, and found that cdc-acm is now broken is a
> ne
On Thu, 15 Apr 2004 20:18:31 +0200
Robert Schwebel <[EMAIL PROTECTED]> wrote:
> the usbserial driver can have two parameters, vendor=0x and
> product=0x. Currently they are defined as 'h' which is 16 bit
> (correct), but _signed_. This means that IDs larger than 0x7FFF do not
> work right
Hi,
the usbserial driver can have two parameters, vendor=0x and
product=0x. Currently they are defined as 'h' which is 16 bit
(correct), but _signed_. This means that IDs larger than 0x7FFF do not
work right now.
The fix below is my quickhack - maybe somebody has a better idea.
Robert
Hi,
cdc-acm was broken since after 2.6.4, due to the alt_cursetting changes. I sent a
patch, which has been integrated (well, the same one has ;-)) not long ago.
I gave 2.6.6-rc1 a try, and found that cdc-acm is now broken is a new way:
when plugging the phone, acm_probe() fails on interface #0;
On Thu, 15 Apr 2004 00:45:09 +0200
Sancho Dauskardt <[EMAIL PROTECTED]> wrote:
> attached is a patch against 2.4.25 for the Adaptec USB2Xchange USB 2.0
> --> SCSI converter.
Please do not compress next time.
> This does two things (two kernel config options):
> 1. Send Adaptec binary firmware
VIRUS ALERT
Our virus checker found
virus: Worm.SomeFool.Gen-1
banned filename: your_document.pif
in your email to the following recipient:
-> [EMAIL PROTECTED]
Delivery of the email was stopped!
Please check your system for viruses,
or ask your system administrator to do so.
For your r
Ни для кого не секрет, что успех любого дела зависит от того, насколько
мотивированы сотрудники на его выполнение.
У Вас отличная команда, но сотрудники не горят желанием работать? Все можно исправить!
Как
сделать так, чтобы сотрудники с энтузиазмом работали,
не требуя бесконечных прибавок к зарп
Kari Veneranta wrote:
// Function Configuration Descriptor
DESCRIPTOR FConf_desc[L_F_CONFIG] PROGMEM =
{
Looks like your driver's configuration descriptor isn't being
delivered as you expect. For example, the wTotalLength of what
Linux sees is 0x0019 not 0x0029, iConfiguration is zero not 2,
bmAt
Andrew Zabolotny wrote:
On Wed, 14 Apr 2004 14:51:47 -0700
Greg KH <[EMAIL PROTECTED]> wrote:
Here are some USB patches for 2.6.5. Almost all of these have been in
Sorry for a possibly dumb question, will these patches be incorporated in
the 2.6.6 mainstream kernel? I'm not quite common with the
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
[EMAIL PROTECTED]
SMTP error from remote mailer after RCPT TO:<[EMAIL PROTECTED]>:
On Thu, 15 Apr 2004, Johan Braeken wrote:
> I read about the "scsiglue.c" file on this mailinglist and decided to do some
> testing.
> With a "max_sectors" value of 16 I got the fastest transferrate, so my slow
> USB problem is solved. (Although it is not a real solution.)
> The transferrate imp
Greg:
I just noticed your new usb_get/put_intf() functions. Creating them is a
tacit admission that drivers will need to continue using interfaces after
their disconnect() routine has returned. Is this wise?
The current assumption in usbcore is that when disconnect() returns the
driver will
Han Pilmeyer wrote:
Hi,
Got the following message with a 2.6.5 kernel:
usb 1-2: new full speed USB device using address 7
usb-storage: This device (07cf,1001,5010 S 05 P 01) has an unneeded Protocol entry in
unusual_devs.h
Please send a copy of this message to <[EMAIL PROTECTED]>scsi1 : SCSI
Pete Zaitcev wrote:
...
This is insane, Alan. There must be a better way.
Alan is the one that always answers the mails concerning this device, so is
probably fed up with this casio QV [EMAIL PROTECTED] camera :)
Anyway, if you want to go with a "new flag" approach, here is a patch. It is not
Hi,
Got the following message with a 2.6.5 kernel:
usb 1-2: new full speed USB device using address 7
usb-storage: This device (07cf,1001,5010 S 05 P 01) has an unneeded Protocol entry in
unusual_devs.h
Please send a copy of this message to <[EMAIL PROTECTED]>scsi1 : SCSI emulation for
USB M
On Thu, 15 Apr 2004, Duncan Sands wrote:
> > > The "if" cannot be optimized away for the case in point, because it
> > > does something (clears the bit) if it passes the test. If I used WARN_ON
> > > then it would have to be WARN_ON(1) in the else branch of the if.
> >
> > True. You should use BU
Hi to All.
Finally I've found the patch that caused my bluetooth device to don't work
anymore.
I've applied the patch sent by Greg KH to Linus yesterday in these order (to
make them apply correctly):
01-Do short packet detection correctly
02-Improved handling of short control transfers
03-Get
On Tuesday 13 April 2004 21:03, Alan Stern wrote:
I read about the "scsiglue.c" file on this mailinglist and decided to do some
testing.
With a "max_sectors" value of 16 I got the fastest transferrate, so my slow
USB problem is solved. (Although it is not a real solution.)
The transferrate impro
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed.
[EMAIL PROTECTED]
Reporting-MTA: dns;GYEX1-SERVER.htwchina.com
Received-From-MTA: dns;ibm3500.htwchina.com
Arrival-Date: Thu, 15 Apr 2004 17:33:57 +0800
Final-Recipient: rfc822
> > The "if" cannot be optimized away for the case in point, because it
> > does something (clears the bit) if it passes the test. If I used WARN_ON
> > then it would have to be WARN_ON(1) in the else branch of the if.
>
> True. You should use BUG_ON().
>
> If this ever happens the device tree is
Am Donnerstag, 15. April 2004 10:47 schrieb Duncan Sands:
> > > Hi Oliver, I thought you meant that CONFIG_EMBEDDED made WARN_ON go
> > > away (or something like that). If you just mean that it is easy to
> > > redefine WARN_ON by hand, then all I can say is: it is also easy to
> > > redefine warn
On Wednesday 14 April 2004 22:39, Oliver Neukum wrote:
> > > I would prefer a real WARN_ON() so that the imbedded people compiling
> > > for size are not affected.
> >
> > What do you mean? How is a real WARN_ON() better?
>
> WARN_ON can be defined away to make a smaller kernel. Code that does
> n
> > Hi Oliver, I thought you meant that CONFIG_EMBEDDED made WARN_ON go away
> > (or something like that). If you just mean that it is easy to redefine
> > WARN_ON by hand, then all I can say is: it is also easy to redefine warn
> > by hand! Anyway, I made you the following patch:
>
> Yes, but I
(cc linux-usb-devel)
Norbert Preining <[EMAIL PROTECTED]> wrote:
>
> Hi USB developers!
>
> Hopefully you can help tracking down the following problem:
>
> I am using the -mm series of linux kernels which includes the current
> bitkeeper usb tree (AFAIS).
>
> Now I cannot get pilot-xfer/jpilot
Hi all,
I am working on new, non standard device which will be connected to USB
port. It is first time that I am dealing with USB port in programming
aspect. I am looking for some piece of code written in C, to start with
simple read/write operations. I have early deadlines, can anybody help?
Tha
Am Donnerstag, 15. April 2004 10:05 schrieb Duncan Sands:
> On Wednesday 14 April 2004 22:39, Oliver Neukum wrote:
> > > > I would prefer a real WARN_ON() so that the imbedded people compiling
> > > > for size are not affected.
> > >
> > > What do you mean? How is a real WARN_ON() better?
> >
> >
Hi USB developers!
Hopefully you can help tracking down the following problem:
I am using the -mm series of linux kernels which includes the current
bitkeeper usb tree (AFAIS).
Now I cannot get pilot-xfer/jpilot/whatever to successfully syncronize
*big* files (like peditPro, DateBk5) to the pal
Hi
More information about the case as asked.
My kernel version is 2.4.25
My port mean what is says in dmesg when i plug my device. ( So yes there
is two physical connectors and one virtual connector in my hub ( to down
stream ). Here is what dmesg is saying from it. ( i have but some debug
in
56 matches
Mail list logo
