On Sat, 2002-03-16 at 05:45, Mark McClelland wrote:
> >Comment #2 (the negative one)
> >
> >What an utter waste of time.
> >
> >I'm sorry to say this, and I've thought for a while if I even should
> >mention this, but this is how I feel about it.
>Yes, but I'd have to make my driver ready for V
As Dave Jones said a few weeks ago,
"Being a maintainer is hard work. Let's go shopping."
Anyway, it sounds like you've fallen behind on 2.5.x
changes a bit, and so have I.
However, I do try to keep a summary list of them at
http://www.osdl.org/archive/rddunlap/linux-port-25x.html
It may be
Nemosoft Unv. wrote:
>Comment #2 (the negative one)
>
>What an utter waste of time.
>
>I'm sorry to say this, and I've thought for a while if I even should
>mention this, but this is how I feel about it.
>
Hey, it wasn't my patch. :-) I must admit that I liked the changes
though. V4L drivers
> But now I hear from two different sides: "we're going to do things
> completely different", and that ticks me off. "Not now, please!" And
> frankly, IMO the V4L1.1 changes don't add much value.
IMHO For 2.4 if it needs driver updating to keep compatible its a bad idea.
For 2.5, go break it al
> Why not just use the proper __attribute__((aligned(L1_CACHE_BYTES)))
> statement within the structures, or use the L1_CACHE_ALIGN macro which
> is defined in cache.h?
This patch is outdated. I removed the macro. Greg and Linus already
applied the changes. It makes _no_ difference if we are t
Hello,
On Friday 15 March 2002 23:45, Mark McClelland wrote:
> Nemosoft Unv. wrote:
> >You mean the introduction of V4L2? Well, if that happens I will
> > *probably* abandon the 2.4 driver; more or less what I did with the 2.2
> > series. But the driver is complete enough. But that's my call :-)
On Sat, Mar 16, 2002 at 02:06:19AM +0100, Anders Gustafsson wrote:
> drivers/usb/pegasus.h and drivers/usb/CDCEther.h defines private
> ALIGN-macros which collides with the macro in
> include/linux/cache.h. This patch renames the private macros to
> avoid this.
Why not just use the proper __attri
drivers/usb/pegasus.h and drivers/usb/CDCEther.h defines private
ALIGN-macros which collides with the macro in
include/linux/cache.h. This patch renames the private macros to
avoid this.
--
//anders/g
--- linux-2.5.7-pre1/drivers/usb/CDCEther.h Thu Feb 21 09:57:46 2002
+++ linux-2.5.7-pre1
On Fri, Mar 15, 2002 at 03:56:16PM -0800, David Brownell wrote:
> Sure, life will be easier if this stuff is all done in 2.5, and
> the next iteration will shift to a 2.5 base. I haven't been
> all that worried about these "swap to usb-storage" issues
> so far anyway ... not when the driver still
Sure, life will be easier if this stuff is all done in 2.5, and
the next iteration will shift to a 2.5 base. I haven't been
all that worried about these "swap to usb-storage" issues
so far anyway ... not when the driver still says it doesn't
guarantee data integrity!
> > And the usb-uhci driver
> > - As a flag for whether the HCD owned the URB, now
> > handled by a new urb->transfer_flags bit. (Strictly
> > speaking, this probably shouldn't be needed, but
> > getting rid of such tests would be risky.)
>
> With using transfer_flags in this way you have introduced a
> > > >Not entirely true. OHCI tries to safeguard against broken drivers,
> > > >and in 2.5 anything using the new HCD code in usbcore does the
> > > >same safeguarding. (Such as EHCI ...) The UHCI drivers may do
> > > >things differently.
> > >
> > > Actually I would not call it broken driver.
On Thu, Mar 14, 2002 at 06:53:53PM +0100, Wolfgang Mües wrote:
> Hello,
>
> I am using Kernel 2.4.10 as Target. I have tried to run my driver in SMP mode,
> but the probe() function is locking the whole system, on the first sleep.
>
> Is there a bug in 2.4.10 which forbidds sleeping in probe ?
On Fri, Mar 15, 2002 at 01:49:49PM -0800, David Brownell wrote:
> And the usb-uhci driver is rather
> convoluted in some ways, it's worth a closer look.
Any reason why you ripped out the CONFIG_DEBUG_SLAB logic from this
driver?
thanks,
greg k-h
___
On Fri, Mar 15, 2002 at 01:49:49PM -0800, David Brownell wrote:
> It's against 2.4.19-pre2 but it should be brought over to 2.5
> soonish (after more testing). It started against pre3, but that
> wouldn't boot for me -- applies there with fuzz. I did sanity
> testing with each of the HCDs (enumer
> > >Not entirely true. OHCI tries to safeguard against broken drivers,
> > >and in 2.5 anything using the new HCD code in usbcore does the
> > >same safeguarding. (Such as EHCI ...) The UHCI drivers may do
> > >things differently.
> >
> > Actually I would not call it broken driver. I think it
On Friday 15 March 2002 23:04, Maksim Krasnyanskiy wrote:
> > > Is it valid to assume that if disconnect method is running completion
> > > handler for bulk transfers will be called _only_ as a result of
> >
> > usb_unlink_urb ?
> >
> > > assuming that urb doesn't have a timeout of course.
> >
> >
Nemosoft Unv. wrote:
>On Friday 15 March 2002 18:19, Greg KH wrote:
>
>>Also realize that the v4l interfaces are changing right now in 2.5, so
>>you will end up with two different drivers over time.
>>
>You mean the introduction of V4L2? Well, if that happens I will *probably*
>abandon the 2.4 d
> - As a flag for whether the HCD owned the URB, now
> handled by a new urb->transfer_flags bit. (Strictly
> speaking, this probably shouldn't be needed, but
> getting rid of such tests would be risky.)
With using transfer_flags in this way you have introduced a race
with
> > > HCD and USB core do not unlink URBs on device disconnect because currently
> > > it is driver's responsibility.
> >
> >Not entirely true. OHCI tries to safeguard against broken drivers,
> >and in 2.5 anything using the new HCD code in usbcore does the
> >same safeguarding. (Such as EHCI ..
> > Is it valid to assume that if disconnect method is running completion
> > handler for bulk transfers will be called _only_ as a result of
> usb_unlink_urb ?
> > assuming that urb doesn't have a timeout of course.
>
>No, this is not the case.
>The only guarantee you have to make. On return fr
> > HCD and USB core do not unlink URBs on device disconnect because currently
> > it is driver's responsibility.
>
>Not entirely true. OHCI tries to safeguard against broken drivers,
>and in 2.5 anything using the new HCD code in usbcore does the
>same safeguarding. (Such as EHCI ...) The UHC
> > It's _supposed_ to be the case that after all driver disconnect()
> > methods (for each claimed interface) are called, then the device
> > refcount goes down to one (no more refs from active URBs). The
> > usbcore-internal usb_disconnect() routine, AFTER all drivers have
> > disconnected, is
> > Rather than constantly allocating and re-allocating urb-private
> > data as each request gets down to the HCD, it'd seem simpler
> > to just preallocate it -- once, inside the URB. "uhci" would seem
> > to want 64 bytes (on 32bit hardware), the other drivers much less.
> > (While usb-ohci cur
On Fri, Mar 15, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > HCD and USB core do not unlink URBs on device disconnect because currently
> > > > it is driver's responsibility.
> > >
> > > Not entirely true. OHCI tries to safeguard against broken drivers,
> > > and in 2.5 anything usin
> > > HCD and USB core do not unlink URBs on device disconnect because currently
> > > it is driver's responsibility.
> >
> > Not entirely true. OHCI tries to safeguard against broken drivers,
> > and in 2.5 anything using the new HCD code in usbcore does the
> > same safeguarding. (Such as EH
> Is it valid to assume that if disconnect method is running completion
> handler for bulk transfers will be called
> _only_ as a result of usb_unlink_urb ? assuming that urb doesn't have a
> timeout of course.
No, this is not the case.
The only guarantee you have to make. On return from disconn
On Fri, Mar 15, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> Maksim Krasnyanskiy <[EMAIL PROTECTED]> asks:
>
> > HCD and USB core do not unlink URBs on device disconnect because currently
> > it is driver's responsibility.
>
> Not entirely true. OHCI tries to safeguard against broken driv
Maksim Krasnyanskiy <[EMAIL PROTECTED]> asks:
> HCD and USB core do not unlink URBs on device disconnect because currently
> it is driver's responsibility.
Not entirely true. OHCI tries to safeguard against broken drivers,
and in 2.5 anything using the new HCD code in usbcore does the
same saf
Hello,
On Friday 15 March 2002 18:19, Greg KH wrote:
> > You know, I would really apreciate it if people would send me the
> > necessary patches as well (the E-mail address is in every pwc file),
> Ah, but this is one of the _advantages_ of open source, other people
> fixing things in your code
> > btw What will happen if unlink_urb is called while completion handler is
> > running ?
>
>An error code will be returned.
Good.
One more question.
HCD and USB core do not unlink URBs on device disconnect because currently
it is driver's responsibility.
Is it valid to assume that if disconne
On Fri, Mar 15, 2002, Maksim Krasnyanskiy <[EMAIL PROTECTED]> wrote:
>
> > > How about ENXIO error in submit_urb ? Should we fix uhci ?
> >
> >Yes, it needs to be fixed and it's relatively easy. I'll send a patch to
> >Greg when I get a chance to test it.
> Looks like we can simply get rid of uhc
> > How about ENXIO error in submit_urb ? Should we fix uhci ?
>
>Yes, it needs to be fixed and it's relatively easy. I'll send a patch to
>Greg when I get a chance to test it.
Looks like we can simply get rid of uhci_call_completion(urb) at the end of
uhci_submit_urb.
I'm not sure why would you
> Take a look here
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/bluez/kernel/drivers/hci_usb
>.c?rev=1.1.1.1&content-type=text/vnd.viewcvs-markup hci_usb_unlink_urbs does
> unlinking on disconnect.
> hci_usb_tx_complete is a completion handler for bulk out transfers.
> I don't have to hold qu
> > Sure. I meant that control transaction has not completed.
> > It doesn't make sense to start new transfer before acknowledging current
> > one. Or does it ?
>
>Somebody in the device firmware has exchanged two lines.
>You have to deal with it. The world is unfair :-)
Yeah. I found a work arou
On Thu, Mar 14, 2002 at 10:59:41PM +0530, Imtiaz Ur Rahamon M. wrote:
> Hi list..
>
> I want to port the USB driver stack (usb-uhci.o, usbcore.o & scanner.o
> -- for scanner) from the kernel to the user space
Um, why?
> I need detailed info about the interfaces & the data structures used
>
On Thu, Mar 14, 2002 at 02:21:47PM +0100, Olaf Hering wrote:
> > The problem looks like the usbdevfs calls are happening at the same time
> > the hid driver is also talking to the device.
> >
> > Olaf, is this what your log messages show?
>
> It seems so. I think a more correct fix would be a lo
On Thu, Mar 14, 2002 at 03:31:20PM +0530, V Ganesh wrote:
> here's the patch updating all serial drivers to correctly use GFP_ATOMIC
> where necessary. in many cases, GFP_KERNEL was being used with kmalloc() in
> functions which could be called in bh context. this has also been fixed.
> a couple o
On Fri, Mar 15, 2002 at 01:49:45PM +0100, Nemosoft Unv. wrote:
> Hello,
>
> On Monday 11 March 2002 18:38, Greg KH wrote:
> > On Sun, Mar 10, 2002 at 02:42:29AM +0100, Nemosoft Unv. wrote:
> > > The patch is not against a kernel version; rather, it is extracted from
> > > my own CVS repository. H
39 matches
Mail list logo
