It seems there are encoding problems in the body of the email,
due to different languages.
Please accept the _same_ patch as .gz attachments (text-attachments
give the same problems). The patch also replaces accented characters
with non-accented ones in French/Italian names, so that I will be
ab
[EMAIL PROTECTED] wrote:
hi all,
i found on windows usb sdk a urb function called URB_FUNCTION_ABORT_PIPE ..
do you know why is not implemented on linux usb driver?
Interesting. Alan Stern had recently proposed implementing
something that sounds very similar. Linux 2.6 has this
function internal
Ole Morten Rønning (AS/ETO) wrote:
Hello group.
Can anyone please tell me the state of the RNDIS protocol support for CDC-Ethernet in the USB-gadget stack?
I've pinged the folk working on it, I hope there will be a
response. Last I heard, there was initial success ... but
from reading RNDIS "spe
PS: Here is the patch that fixed the original usbfs Oops, but gained the new
one Vince reported:
Good -- more locks vanishing from usbcore; it's about time!
This is a case where fewer locks are better.
My main patch feedback here would be that it should merge
most of the usbfs patch I sent (second
On Thu, Dec 04, 2003 at 10:21:52AM -0500, Alan Stern wrote:
> Greg:
>
> This patch adds to unusual_devs.h an entry reported by Andries Brouwer and
> it moves another entry to the correct position in the numerical ordering.
Applied, thanks.
greg k-h
On Fri, Nov 21, 2003 at 02:52:55PM -0500, Alan Stern wrote:
> On Thu, 20 Nov 2003, Stefan J. Betz wrote:
>
> > Hello People,
> >
> > i have some Mitsumi USB Floppy Drive with the following Data:
> > Manufactur: Mitsumi
> > Typ : D353FUE
> >
> > When i plug this Device into my Linux Box (Ke
On Wed, Nov 12, 2003 at 02:41:31PM -0500, Alan Stern wrote:
> Greg:
>
> Here is another update for unusual_devs.h in both 2.6 and 2.4. No
> urgency.
Applied, thanks.
greg k-h
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Becom
On Sun, Nov 09, 2003 at 05:48:41PM +0100, Henning Meier-Geinitz wrote:
> Hi,
>
> Added vendor/product ids for Epson, Genius, Microtek, Plustek,
> Reflecta, and Visioneer scanners. Removed ids for HP PSC devices as
> these are supported by the hpoj userspace driver.
Applied, thanks.
greg k-h
--
Oliver Neukum wrote:
(1) If both subsys.rwsem and dev->serialize are taken, then
subsys.rwsem must be taken first.
Yes.
Erm, no. As I pointed out the other day, it's a locking
hierarchy. It must always go the other way:
- dev->serialize first. That controls the existence
of the devices rep
> How about instead changing
>
> > dev->toggle[out] |= bit << ep;
>
> to
>
> > if (bit)
> > dev->toggle[out] |= 1 << ep;
>
> Less efficient, but if it avoids a bug it's worth it.
What about
dev->toggle[out] |= (!!bit) << ep;
?
Duncan.
PS: Since the previous version
On Sat, Dec 06, 2003 at 01:55:39PM +0100, Luca Risolia wrote:
> Important updates and cleanups and small bug fixes.
>
> Greg, please apply.
Hm, I get the following errors when trying to apply this patch:
$ patch -p1 -g1 --dry-run < ../u2
CREDITS 1.74: 3455 lines
patching file CREDITS
Hunk #1 F
On Wed, Dec 10, 2003 at 05:27:31PM -0800, Greg KH wrote:
>
> Here are some USB fixes for 2.6.0-test11. They all fix real bugs, and
> are 1-4 line fixes with the exception of the usb-serial close() fix,
> which is a bit larger, but has been well tested by a number of different
> users.
>
> Please
On Thu, Dec 11, 2003 at 12:38:35PM -0500, Gene Heskett wrote:
> On Thursday 11 December 2003 11:46, Greg KH wrote:
> >On Thu, Dec 11, 2003 at 07:12:08AM -0500, Gene Heskett wrote:
> >> Can anyone tell me the state of this device vis-a-vis full duplex
> >> operation with hardware flow control? With
On Thursday 11 December 2003 11:46, Greg KH wrote:
>On Thu, Dec 11, 2003 at 07:12:08AM -0500, Gene Heskett wrote:
>> Can anyone tell me the state of this device vis-a-vis full duplex
>> operation with hardware flow control? With software xon/xoff?
>
>Yes, it should work. What kernel version are y
On Thu, 11 Dec 2003, Robert C Lorentz wrote:
> I've been urged to email you, so here it is! I never saw this message
> until 2.6.0-test5. I know this isn't the most recent kernel and I know
> it's dev, but I figured it's better to report a bug than keep my mouth
> shut. Hope this helps! (Immed
On Thu, Dec 11, 2003 at 07:12:08AM -0500, Gene Heskett wrote:
> Can anyone tell me the state of this device vis-a-vis full duplex
> operation with hardware flow control? With software xon/xoff?
Yes, it should work. What kernel version are you using?
> I have one, and it seems I can type in min
I've been urged to email you, so here it is! I never saw this message
until 2.6.0-test5. I know this isn't the most recent kernel and I know
it's dev, but I figured it's better to report a bug than keep my mouth
shut. Hope this helps! (Immediately relevant entry highlighted near
bottom of email
On Wed, 10 Dec 2003, David Brownell wrote:
> > More importantly, usb_sg_request doesn't have completion handlers. It's
> > not really asynchronous, in the sense that drivers eventually have to wait
> > for a request to complete.
>
> It's always been an explicitly synchronous model -- no comple
On Thu, 11 Dec 2003, Duncan Sands wrote:
> On Wednesday 10 December 2003 19:19, Alan Stern wrote:
> >
> > I don't understand the problem. What's wrong with dropping dev->serialize
> > before calling usb_reset_device() or usb_set_configuration() and then
> > reacquiring it afterward?
>
> The prob
On Wed, 10 Dec 2003, Rogério Brito wrote:
> Some other points that I don't remember if I told you: in my old
> notebook, I can plug the drive and unplug it as many times as I please
> and it is always recognized.
>
> With my desktop, the situation is quite a bit different: in those rare
> circums
On Thu, 11 Dec 2003, Rogério Brito wrote:
> Well, the fact that it sometimes works and sometimes doesn't can be
> indicative that there's a race condition somewhere, right?
Not necessarily. It could easily be a hardware issue.
> I don't remember if I mentioned this, but this device is actually
On Thu, 11 Dec 2003, Duncan Sands wrote:
> Hi Josep, does the following also work?
>
> --- usb.h.orig2003-12-11 14:29:08.0 +0100
> +++ usb.h 2003-12-11 14:29:16.0 +0100
> @@ -1005,7 +1005,7 @@
> static inline void usb_settoggle(struct usb_device *dev,
>
> Change this:
>
> static inline void usb_settoggle(struct usb_device *dev,
> unsigned int ep,
> unsigned int out,
> int bit)
> {
> dev->toggle[out] &= ~(1 << ep);
> dev->toggle[out] |= bit << ep;
> }
>
> by this:
>
> #define usb_settoggle(dev, ep, out, bit) ((dev)->toggle[out] =
> ((dev)->toggle[o
On Tuesday 09 December 2003 11:46, fee mail wrote:
> I guess this patch have been missed so I resend it as 2 rc more and still
> not applied or rejected. Begin forwarded message:
I guess Greg is waiting for Johannes to review it.
Ciao,
Duncan.
--
Can anyone tell me the state of this device vis-a-vis full duplex
operation with hardware flow control? With software xon/xoff?
I have one, and it seems I can type in minicom and it shows up on the
other end, or I can type from the other end and it shows up on the
minicom screen, but if I star
>> Any help would be greatly appreciated.
>
>You are using kernels configured with CONFIG_USB_HIDDEV, aren't you?
>
> Regards
> Oliver
An excellent question.
(Here's where I sheepishly ask...)
How do I find out?
I assumed (in the 2.4.20-8 kernel) that all of the HID support t
Am Donnerstag, 11. Dezember 2003 10:45 schrieb Duncan Sands:
> > > > > __usb_set_configuration - lockless version
> > > > > usb_set_configuration - locked version
> > > >
> > > > Partially done.
> > > > That's what the _physical version of usb_reset_device() is about.
> > >
> > > Unfortunately, usb
> > > > __usb_set_configuration - lockless version
> > > > usb_set_configuration - locked version
> > >
> > > Partially done.
> > > That's what the _physical version of usb_reset_device() is about.
> >
> > Unfortunately, usb_physical_reset_device calls usb_set_configuration
> > which takes dev->ser
On Wednesday 10 December 2003 18:21, David Brownell wrote:
> [ CC list trimmed, most folk are on one of the cc'd lists ]
>
> > By the way, here is the list of routines that cause trouble for usbfs:
Hi Dave, by "they cause trouble" I meant: they may take, or lead to
taking, dev->serialize. This me
On Wednesday 10 December 2003 19:19, Alan Stern wrote:
> On Wed, 10 Dec 2003, Duncan Sands wrote:
> > On Wednesday 10 December 2003 18:34, David Brownell wrote:
> > > > Unfortunately, usb_physical_reset_device calls usb_set_configuration
> > > > which takes dev->serialize.
> > >
> > > Not since lat
[EMAIL PROTECTED] wrote:
From: Eduard Hasenleithner <[EMAIL PROTECTED]>
As the command set of the datafab driver still may offer two luns we
might have three luns in total.
That is not the right point of view.
The command set of a SCSI device allows for example 8 luns,
but that does n
> If the file is open, keep the reference count. If you were to try
> anything else, it would just be to complex in the end.
>
> It's ok to wait a long time on rmmod, that's a pretty unique situation.
Great - thanks.
Duncan.
---
This SF.net e
On Thu, Dec 11, 2003 at 09:49:54AM +0100, Duncan Sands wrote:
>
> Hi Greg, what I meant was: should I make my patch friendlier to rmmod by
> trying hard to drop the reference as soon as possible, though some code paths
> may have to hold on to it for a long time (cost: code complication), or is it
On Wednesday 10 December 2003 20:43, David Brownell wrote:
> Duncan Sands wrote:
> > On Wednesday 10 December 2003 18:34, David Brownell wrote:
> >>>Unfortunately, usb_physical_reset_device calls usb_set_configuration
> >>>which takes dev->serialize.
> >>
> >>Not since late August it doesn't ...
>
> > I don't know if you've been following this thread or not, but the oops
> > occurred when I modified usbfs to hold a reference to the usb_device
> > until no-one was using a given usbfs file.
>
> That's a good thing to do. It should work.
>
> > I guess this means that I should change my patch s
1. Problem: Kernel 2.4.23 fails to talk to device via the usb-uhci module
2 I have a USB camera (Labtec web cam) which worked under kernel 2.4.22,
but is not recognized at all by the usb system when plugged in under
2.4.23.
3 modules usb
4. Linux version 2.4.23 ([EMAIL PROTECTED]) (gcc version 2.9
Hello group.
Can anyone please tell me the state of the RNDIS protocol support for CDC-Ethernet in
the USB-gadget stack?
For a product, due to delivery in April/March -04, would you suppose we would have to
supply a Windows CDC-Ethernet driver for a Windows PC to
talk to our Linux gadget, or
hi all,
i found on windows usb sdk a urb function called URB_FUNCTION_ABORT_PIPE ..
do you know why is not implemented on linux usb driver?
Can it be compared with USBDEVFS_CLEAR_HALT urb linux function?
thnx in advance
Kolja
---
This SF.net
On Wed, Dec 10, 2003 at 05:08:12PM -0500, Alan Stern wrote:
> > Now grasshopper, are you wise in the ways of the driver core or are you
> > wishing you never asked? :)
>
> Both, I think. I still don't see where pci_unregister_driver() ends up
> waiting for the reference count to drop to 0. In f
On Thu, Dec 11, 2003 at 03:10:33AM +0100, Vince wrote:
> I've tried this patch together with Duncan's fix for my first problem
> and I couldn't reproduce any oops on my system. I've only tried a few (a
> dozen) cyles of loading/unloading for now (but earlier that was much
> enough to trigger an
40 matches
Mail list logo
