Hello,
First I just want read 2 bytes sent by my device (the pic16c745/765). They are located
in EP1.
That communication send to the PC under linux2.4.20 (that works properly because I
have do it under windows and
it worked) and it uses the transfer interrupt.
Now I use the fields of structure
On Tuesday 27 July 2004 04:41 pm, Sebastian Spaeth wrote:
> From: Dmitry Torokhov
> Date: 2004-07-20 4:04:47
>
> >Hopefully if send the patch directly to you you will be able to apply
> >it. Just save entire mail as a text and feed it to patch.
> >
> >Please let me know if it work
On Thursday 29 July 2004 14:11, Oliver Neukum wrote:
>
> > Make that "weeks or months", not seconds ... then it's a lot more
> > evident what the real problem is ... not copy to/from userspace,
> > but long-term blocking until URBs complete. :)
>
> OK, this is a serious problem.
>
> [..]
> > So
On Thursday 29 July 2004 14:55, Alan Stern wrote:
> On Thu, 29 Jul 2004, David Brownell wrote:
>
> > > Our work on the hub driver is well on its way to getting hopelessly
> > > tangled. Should we try to coordinate the changes we've been sending in
> > > independently?
> >
> > This looked OK to
On Thu, 29 Jul 2004, Pete Zaitcev wrote:
> > Remember also that disconnect() occuring while an URB is active will cause
> > the URB to be aborted. So it ought to be enough to unlock the device
> > before submitting the URB.
>
> What if the disconnect thread has time to free the device struct w
On Thu, 29 Jul 2004, David Brownell wrote:
> > Our work on the hub driver is well on its way to getting hopelessly
> > tangled. Should we try to coordinate the changes we've been sending in
> > independently?
>
> This looked OK to me with respect to RC2 and to what's in Greg's tree
> (except f
On Thu, 29 Jul 2004 17:02:42 -0400 (EDT)
Alan Stern <[EMAIL PROTECTED]> wrote:
> On Thu, 29 Jul 2004, Greg KH wrote:
>
> > On Thu, Jul 29, 2004 at 10:59:09AM -0700, Pete Zaitcev wrote:
> > >
> > > The patch attached to OSDL 3108 does not look good to me. The right
> > > approach would be to do u
this is what the kernel says when I plug in this Lacie
USB HD (model
EK0-U-HD-705475). After plugging it in "cat
/proc/scsi/scsi" returns nothing.
Thanks,
Chris
<7>ehci_hcd :00:02.2: GetStatus port 1 status
003802 POWER OWNER sig=j
CSC
<7>hub 1-0:1.0: port 1, status 0, change 1, 12 Mb/s
<
> Make that "weeks or months", not seconds ... then it's a lot more
> evident what the real problem is ... not copy to/from userspace,
> but long-term blocking until URBs complete. :)
OK, this is a serious problem.
[..]
> So that'd be patches 17 and 18 that are IMO very worth merging,
> with so
On Thu, 29 Jul 2004, Greg KH wrote:
> On Thu, Jul 29, 2004 at 10:59:09AM -0700, Pete Zaitcev wrote:
> >
> > The patch attached to OSDL 3108 does not look good to me. The right
> > approach would be to do usb_dev_get to prevent disconnect from pulling
> > things from under you, then submit URBs.
>
On Thursday 29 July 2004 13:18, Alan Stern wrote:
> David:
>
> Our work on the hub driver is well on its way to getting hopelessly
> tangled. Should we try to coordinate the changes we've been sending in
> independently?
This looked OK to me with respect to RC2 and to what's in Greg's tree
(ex
Greg:
This patch fixes a NULL-pointer-dereference bug in the dummy_hcd driver.
It also makes the code slightly more elegant and removes an unnecessary
buffer-overflow test. Unfortunately it's still a little bit racy, but
this is a fault it shares with other gadget controller drivers, like
net22
Greg:
This patch follows the suggestions sent by Todd Fischer and Diego Dompe
for making removable-LUN support part of the normal non-testing version of
the g_file_storage driver. It also moves LUN device registration to the
correct place and eliminates a code path that stalls the bulk-out pipe
On Thursday 29 July 2004 11:40, Greg KH wrote:
> On Thu, Jul 29, 2004 at 08:24:33PM +0200, Oliver Neukum wrote:
> > Am Donnerstag, 29. Juli 2004 19:54 schrieb Greg KH:
> > > On Thu, Jul 29, 2004 at 06:19:15PM +0200, Duncan Sands wrote:
> > > > Rather than taking the semaphore dev->serialize in the
David:
Our work on the hub driver is well on its way to getting hopelessly
tangled. Should we try to coordinate the changes we've been sending in
independently?
With regard to your latest patch, I have some questions/comments:
There's no need to check hub->quiescing in the interrupt
Please merge; the CONFIG_USB_SUSPEND patch depends on it.
- Dave
This hub patch:
- updates internal docs about locking, matching current usage
for device state spinlock and dev->serialize semaphore
- adds locktree() to use with signaling that affect everything
downstream of a given devic
This is the core of the USB_SUSPEND functionality. Please merge.
- Dave
This adds an experimental CONFIG_USB_SUSPEND option, which supports the
USB "suspend" state. Linux-USB hosts have previously ignored that state.
- New driver API calls, usb_suspend_device() and its
sibling usb
On Thu, Jul 29, 2004 at 08:24:33PM +0200, Oliver Neukum wrote:
> Am Donnerstag, 29. Juli 2004 19:54 schrieb Greg KH:
> > On Thu, Jul 29, 2004 at 06:19:15PM +0200, Duncan Sands wrote:
> > > Rather than taking the semaphore dev->serialize in the
> > > top-level ioctl handler, usbdev_ioctl, push it do
Am Donnerstag, 29. Juli 2004 19:54 schrieb Greg KH:
> On Thu, Jul 29, 2004 at 06:19:15PM +0200, Duncan Sands wrote:
> > Rather than taking the semaphore dev->serialize in the
> > top-level ioctl handler, usbdev_ioctl, push it down to the
> > individual ioctl routines. This is a Good Thing because
On Thu, Jul 29, 2004 at 10:59:09AM -0700, Pete Zaitcev wrote:
>
> The patch attached to OSDL 3108 does not look good to me. The right
> approach would be to do usb_dev_get to prevent disconnect from pulling
> things from under you, then submit URBs.
I agree.
greg k-h
--
On Thu, 29 Jul 2004 18:19:15 +0200
Duncan Sands <[EMAIL PROTECTED]> wrote:
> Patches 16/18 and 17/18 (proc_control and proc_bulk) also
> release the semaphore while waiting for the urb to complete.
> This fixes http://bugme.osdl.org/show_bug.cgi?id=3108. You
> may well wonder why I copied some of
On Thu, Jul 29, 2004 at 06:19:15PM +0200, Duncan Sands wrote:
> Rather than taking the semaphore dev->serialize in the
> top-level ioctl handler, usbdev_ioctl, push it down to the
> individual ioctl routines. This is a Good Thing because
> the ioctl routines do plenty of copy_to/from_user calls.
On Thu, 29 Jul 2004 18:24:08 +0200
Duncan Sands <[EMAIL PROTECTED]> wrote:
> This way the pushdown patch for each ioctl routine becomes
> independent of the others.
> --- local_tree.orig/drivers/usb/core/devio.c 2004-07-25 14:34:32.843129288 +0200
> +++ local_tree/drivers/usb/core/devio.c
--- local_tree.orig/drivers/usb/core/devio.c2004-07-26 12:17:18.0 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-29 18:38:16.817733447 +0200
@@ -71,6 +71,7 @@
dev_info( dev , format , ## arg); \
} while (0)
+#define MAX_BUFFER_LENGTH 1
This is actually patch 3/18.
Sorry about that,
Duncan.
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are n
--- local_tree.orig/drivers/usb/core/devio.c2004-07-26 00:55:05.0 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-26 12:17:18.893769249 +0200
@@ -530,71 +530,152 @@
return 0;
}
+static void wakeup_completion(struct urb *urb, struct pt_regs *regs)
+{
+ complete((s
--- local_tree.orig/drivers/usb/core/devio.c2004-07-26 00:34:29.602731436 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-26 00:39:13.980826658 +0200
@@ -1168,10 +1168,17 @@
if (get_user(ifnum, (unsigned int __user *)arg))
return -EFAULT;
- if ((ret = relea
--- local_tree.orig/drivers/usb/core/devio.c2004-07-26 00:39:13.980826658 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-26 00:55:05.361216844 +0200
@@ -1184,11 +1184,12 @@
static int proc_ioctl (struct dev_state *ps, void __user *arg)
{
struct usbdevfs_ioctl ctrl;
- in
--- local_tree.orig/drivers/usb/core/devio.c2004-07-26 00:31:47.183662802 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-26 00:34:29.602731436 +0200
@@ -1148,10 +1148,17 @@
static int proc_claiminterface(struct dev_state *ps, void __user *arg)
{
unsigned int ifnum;
+ int
--- local_tree.orig/drivers/usb/core/devio.c2004-07-26 00:23:41.914115079 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-26 00:31:47.183662802 +0200
@@ -1134,8 +1134,14 @@
return -EFAULT;
if (ds.signr != 0 && (ds.signr < SIGRTMIN || ds.signr > SIGRTMAX))
--- local_tree.orig/drivers/usb/core/devio.c2004-07-26 00:17:25.499847408 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-26 00:23:41.914115079 +0200
@@ -1102,18 +1102,28 @@
{
struct async *as;
void __user *addr;
+ struct usb_device *dev = ps->dev;
int ret;
--- local_tree.orig/drivers/usb/core/devio.c2004-07-26 00:12:27.375116209 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-26 00:17:25.499847408 +0200
@@ -1064,6 +1064,11 @@
struct usb_device *dev = ps->dev;
int ret;
+ down(&dev->serialize);
+ if (!connected(d
On Wed, 28 Jul 2004, Gerhard Jaeger wrote:
> Hi,
>
> okay, before fiddling around with that Windoze driver stuff, I tried your last
> patch (uhci-hcd.c one liner) and removed all other patches, result:
> I worked - at least partially. I have a log attached where both cases can
> be seen. Sometime
--- local_tree.orig/drivers/usb/core/devio.c2004-07-25 23:49:54.978689141 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-26 00:08:48.470761404 +0200
@@ -1010,12 +1010,21 @@
static int proc_unlinkurb(struct dev_state *ps, void __user *arg)
{
struct async *as;
+ struct usb_
--- local_tree.orig/drivers/usb/core/devio.c2004-07-25 15:03:40.103651192 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-25 15:06:59.781312430 +0200
@@ -765,14 +765,22 @@
static int proc_setintf(struct dev_state *ps, void __user *arg)
{
struct usbdevfs_setinterface setintf;
+
--- local_tree.orig/drivers/usb/core/devio.c2004-07-25 15:06:59.0 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-25 23:49:54.978689141 +0200
@@ -785,14 +785,20 @@
static int proc_setconfig(struct dev_state *ps, void __user *arg)
{
- unsigned int u;
- int status =
--- local_tree.orig/drivers/usb/core/devio.c2004-07-25 14:59:32.292267558 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-25 15:03:40.103651192 +0200
@@ -750,8 +750,16 @@
static int proc_resetdevice(struct dev_state *ps)
{
- return __usb_reset_device(ps->dev);
+ struct usb
--- local_tree.orig/drivers/usb/core/devio.c2004-07-25 14:50:11.447716542 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-25 14:59:32.292267558 +0200
@@ -735,12 +735,17 @@
static int proc_connectinfo(struct dev_state *ps, void __user *arg)
{
struct usbdevfs_connectinfo ci;
+
--- local_tree.orig/drivers/usb/core/devio.c2004-07-25 14:38:38.768837204 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-25 14:40:17.687826010 +0200
@@ -677,22 +677,31 @@
static int proc_clearhalt(struct dev_state *ps, void __user *arg)
{
+ struct usb_device *dev = ps->dev;
--- local_tree.orig/drivers/usb/core/devio.c2004-07-25 14:40:17.687826010 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-25 14:50:11.447716542 +0200
@@ -708,21 +708,27 @@
static int proc_getdriver(struct dev_state *ps, void __user *arg)
{
struct usbdevfs_getdriver gd;
+ s
--- local_tree.orig/drivers/usb/core/devio.c2004-07-25 14:37:18.758596644 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-25 14:38:38.768837204 +0200
@@ -654,17 +654,25 @@
static int proc_resetep(struct dev_state *ps, void __user *arg)
{
+ struct usb_device *dev = ps->dev;
This way the pushdown patch for each ioctl routine becomes
independent of the others.
--- local_tree.orig/drivers/usb/core/devio.c2004-07-25 14:34:32.843129288 +0200
+++ local_tree/drivers/usb/core/devio.c 2004-07-25 14:37:18.758596644 +0200
@@ -1180,109 +1180,205 @@
if (!(file->f_mo
Rather than taking the semaphore dev->serialize in the
top-level ioctl handler, usbdev_ioctl, push it down to the
individual ioctl routines. This is a Good Thing because
the ioctl routines do plenty of copy_to/from_user calls.
It's better to acquire the semaphore after copying the data
from the us
Hi. This is the qmail-send program at issv0171.isis.de.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
Sorry, no mailbox here by that name. (#5.1.1)
--- Below this line is a co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> open is much less of an issue because after open I can fork and issue
> two reads anyway. Quite a few drivers simply use a semaphore to
> serialize read operations.
Hmm.. I updated the driver and fixed most issues (indentation and open()).
See http
On Tue, 27 Jul 2004, David Brownell wrote:
> Periodically I think about changing how Linux does this -- to do exactly
> that: request 18 bytes of device descriptor right away to determine
> ep0 maxpacket, and assume it's 64 bytes at first (usually is!) rather
> than just 8 bytes. But I lack time
On Thu, 29 Jul 2004, Wolfgang Mües wrote:
> Hello,
>
> On Wednesday 28 July 2004 21:10, Alan Stern wrote:
>
> > This is still relatively new and hasn't percolated down to the level
> > of the hotplug scripts yet. Nevertheless, in a hotplug script is the
> > right place to do it.
>
> H... i
On Thursday 29 July 2004 00:56, Oliver Neukum wrote:
>
>
> So could the usb_request structure be used on both sides?
With a bit of work from the host controller drivers, yes. (OHCI looked
easy, the others less so.) Then there's the issue of changing host
side device drivers to use that instead
> That's exactly the reason why the gadget API passes the endpoint in
> when allocating a usb_request object (analagous to URB on host side).
> Per-request host-side allocations today are:
>
>-URB
> - URB-private data (different for each HCD)
> - TD (usually just one, except for UHCI or e
Hi. This is the qmail-send program at beta.sigadel.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
Sorry, no mailbox here by that name. vpopmail (#5.1.1)
--- Below this line
Сделай шаг для полной защите.
http://www.dazer2.ru
d at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
51 matches
Mail list logo
