Attached are new drivers for the KB Gear JamStudio Tablet. There are two
files, one is against 2.4.20, the other against 2.5.62. I'm hoping this
isn't too late in the 2.4.21-pre stages to get included (or the 2.5, for
that matter =). This driver Works For Me, on both 2.4.20 and 2.5.62.
Thanks to A
> On Fri, Feb 21, 2003 at 10:04:14PM +0100, Thomas Jarosch wrote:
> > This is a patch against the ftdi_sio 1.3.0 driver + interim patch.
> > The new driver should be out soon...
>
> Can you post it not compressed so we can read it?
Sure. I compressed it to save bandwith...
Thomas
diff -u -r -b d
[Please CC me on replies, I'm not subscribed to the list]
General:
The device in question is a Mackie SDR24/96 24 Track
Hard Disk Recorder, the manufacturer URL is:
http://www.mackie.com/record/sdr2496/index.html
Though I don't believe there are too many Linux
users around that have such
Does this work (without the patch) with 2.5.x? It should, since the latest
2.5.x doesn't keep any data about a device once it's removed.
On Sat, Feb 22, 2003 at 07:53:42PM +0100, Andreas Steinmetz wrote:
> [Please CC me on replies, I'm not subscribed to the list]
>
> General:
>
>
> The
On Sat, Feb 22, 2003 at 09:58:52AM +0100, Thomas Jarosch wrote:
> > On Fri, Feb 21, 2003 at 10:04:14PM +0100, Thomas Jarosch wrote:
> > > This is a patch against the ftdi_sio 1.3.0 driver + interim patch.
> > > The new driver should be out soon...
> >
> > Can you post it not compressed so we can r
> Hm, seems to have dropped all tabs, can you try sending it again so that
> it could be applied properly?
Hmm, just save the compressed version to disk :-)
> One small comment on the code:
> > +typedef struct {
> > + unsigned char enable;
> > + unsigned char bitmask; /* description of bitmask: s
Matthew Dharm wrote:
Does this work (without the patch) with 2.5.x? It should, since the latest
2.5.x doesn't keep any data about a device once it's removed.
I didn't try with 2.5 as I currently can't switch to 2.5 for some
reasons. Nevertheless I don't believe it will work wit 2.5 as
1. the dev
Alan Stern wrote:
I noticed that usb-skeleton.c still has a TODO entry referring to a race
involving urb->status, so I took a closer look. Fixing that race will be
easy, and I will be happy to submit a patch for it. But there are two
FWIW, here's a patch I started to put together (unfinished). F
Duncan Sands wrote:
I get an oops on shutdown with 2.4.20 (speedtouch driver). Here is what
happens:
probe method called: I take a reference to the usb device with usb_inc_dev_use
(machine shutting down - shutdown of usb subsystem)
disconnect called
(still have the reference)
If you still hold
On Saturday 22 February 2003 21:04, David Brownell wrote:
> Duncan Sands wrote:
> > I get an oops on shutdown with 2.4.20 (speedtouch driver). Here is what
> > happens:
> >
> > probe method called: I take a reference to the usb device with
> > usb_inc_dev_use
> >
> > (machine shutting down - shutd
Duncan Sands wrote:
disconnect called
(still have the reference)
If you still hold it after your disconnect() returned, the
bug is in your driver ...
...time passes...
final driver shutdown: I drop the reference using usb_dec_dev_use, which
oopses.
Hi Dave, why is it a bug? I hold a reference
Am Samstag, 22. Februar 2003 00:15 schrieben Sie:
> >>A per-device list is sufficient, and a lot cheaper to maintain.
> >>Doing it per-interface would add work to the submit path that's
> >>hardly ever needed ... better to have that work delayed until
> >>it's actually needed.
> >
> > Then how to i
> The philosophy is often called "programming by contract".
>
> And the contract is: usbcore agrees to work with your driver
> and do everything right, if your driver agrees to do a few
> specific things. One of those specific things is never using
> the device after you return from disconnect(),
On Sun, Feb 23, 2003 at 12:36:02AM +0100, Duncan Sands wrote:
> > The philosophy is often called "programming by contract".
> >
> > And the contract is: usbcore agrees to work with your driver
> > and do everything right, if your driver agrees to do a few
> > specific things. One of those specifi
On Fri, Feb 21, 2003 at 01:12:47PM -0500, Alan Stern wrote:
> I noticed that usb-skeleton.c still has a TODO entry referring to a race
> involving urb->status, so I took a closer look. Fixing that race will be
> easy, and I will be happy to submit a patch for it. But there are two
> other problem
Present for you, Greg! I moved usb_put_dev to the disconnect routine
(of course, there is a usb_get_dev in probe). Now I get the following oops
on 2.5 during system shutdown:
uhci-hcd 00:0b.0: remove, state 3
usb usb1: USB disconnect, address 1
usb 1-2: USB disconnect, address 2
Unable to handle
On Sat, Feb 22, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 23, 2003 at 12:36:02AM +0100, Duncan Sands wrote:
> > > The philosophy is often called "programming by contract".
> > >
> > > And the contract is: usbcore agrees to work with your driver
> > > and do everything right, if your d
On Sun, Feb 23, 2003 at 01:03:31AM +0100, Duncan Sands wrote:
> Present for you, Greg! I moved usb_put_dev to the disconnect routine
> (of course, there is a usb_get_dev in probe). Now I get the following oops
> on 2.5 during system shutdown:
Do you get the same oops if you just try to rmmod the
On Sat, Feb 22, 2003 at 07:13:26PM -0500, Johannes Erdfelt wrote:
>
> The intent was for 2.4 to have this same contract. Having a reference count
> on the device structure is pointless if that weren't the case.
Yes, and because of this, the driver model changes in 2.5 were very
easy, thanks for d
On Sat, 2003-02-22 at 23:36, Duncan Sands wrote:
> > The philosophy is often called "programming by contract".
> >
> > And the contract is: usbcore agrees to work with your driver
> > and do everything right, if your driver agrees to do a few
> > specific things. One of those specific things is n
On Sunday 23 February 2003 01:05, Greg KH wrote:
> On Sun, Feb 23, 2003 at 01:03:31AM +0100, Duncan Sands wrote:
> > Present for you, Greg! I moved usb_put_dev to the disconnect routine
> > (of course, there is a usb_get_dev in probe). Now I get the following
> > oops on 2.5 during system shutdow
On Sunday 23 February 2003 01:03, Duncan Sands wrote:
> Present for you, Greg! I moved usb_put_dev to the disconnect routine
> (of course, there is a usb_get_dev in probe). Now I get the following oops
> on 2.5 during system shutdown:
Mea culpa - I was borking the system just before the call to
Greg KH wrote:
On Sun, Feb 23, 2003 at 12:36:02AM +0100, Duncan Sands wrote:
The philosophy is often called "programming by contract".
And the contract is: usbcore agrees to work with your driver
and do everything right, if your driver agrees to do a few
specific things. One of those specific t
This is fundamentally the problem. Your vision of how stuff is supposed
to work in the USB code is solely your vision and doesn't match what was
intended when I wrote the code or what the majority of the code does.
You can keep thinking whatever you want, but it ain't reality.
ERm, "person 1's cod
Back to the patch I've attached. It's against 2.4.19-pre3 (I'll update
to Greg's CVS tree) and hasn't had the level of testing necessary to
call it good. I also want to recheck that I caught all of the necessary
paths.
Seems like the main change there is that after disconnect, EDs
get cleaned up in
The intent was for 2.4 to have this same contract. Having a reference count
on the device structure is pointless if that weren't the case.
However, there may be bugs there in HCDs, the core, or drivers with
respect to this because it was never clearly defined or enforced.
I just want to point out
On Sat, Feb 22, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > The intent was for 2.4 to have this same contract. Having a reference count
> > on the device structure is pointless if that weren't the case.
> >
> > However, there may be bugs there in HCDs, the core, or drivers with
> > resp
On Sat, Feb 22, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> >>>Back to the patch I've attached. It's against 2.4.19-pre3 (I'll update
> >>>to Greg's CVS tree) and hasn't had the level of testing necessary to
> >>>call it good. I also want to recheck that I caught all of the necessary
> >>>pat
On Sat, Feb 22, 2003 at 06:59:54PM -0800, David Brownell wrote:
> Greg KH wrote:
> >On Sun, Feb 23, 2003 at 12:36:02AM +0100, Duncan Sands wrote:
> >
> >>>The philosophy is often called "programming by contract".
> >>>
> >>>And the contract is: usbcore agrees to work with your driver
> >>>and do e
Okay, I see Linus has now accepted this into his tree. It should propagate
to the USB development trees soon.
One question: What else is needed? We set the device offline,
error/complete all pending commands, and the need to (somehow) make certain
we're in a good state for calling scsi_remove_ho
30 matches
Mail list logo
