Sam Bishop wrote:
On Wednesday 30 August 2006 3:40 am, Franck Bui-Huu wrote:
This patch also fixes a bug in usb_device_poll() at the same time.
Previous code always raised POLLIN bit although no event happened
on the bus.
I believe this is expected behavior. I mentioned it in the patch I
/prob/bus/usb/devices /dev/null
If no event occurs within 5 seconds, it will timeout.
I took a look at drivers/usb/core/devices.c and it seems to be broken.
This patch helps to make things work...
Thanks
Franck
-- 8 --
Subject: [PATCH] usbfs: remove BKL usage in devices.c
Now
; /* true during some HNP roleswitches */
unsigned b_hnp_enable:1;/* OTG: did A-Host enable HNP? */
Franck
-
Using Tomcat but need to do more? Need to support web services, security?
Get
Greg,
Anything wrong with this patch ?
thanks
Franck
Franck Bui-Huu wrote:
This patch uses completion timeout instead of a timer to implement
a timeout when submitting an URB in usb_start_wait_urb().
It also fixes a small issue. With the previous code, if no timeout
occured.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/core/message.c | 73 +---
1 files changed, 29 insertions(+), 44 deletions(-)
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 08fb20f..6213c6d 100644
.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/core/message.c | 73 +---
1 files changed, 29 insertions(+), 44 deletions(-)
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 08fb20f..6213c6d 100644
--- a/drivers
had occured.
Franck
-- 8 --
[PATCH] usbcore get rid of the timer in usb_start_wait_urb()
This patch uses completion timeout instead of a timer to implement
a timeout when submitting an URB in usb_start_wait_urb().
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb
the device's lock for that purpose ?
Franck
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http
Alan Stern wrote:
On Thu, 29 Jun 2006, Franck Bui-Huu wrote:
BTW, I updated the patch and I think it fixes a small issue. With the
previous code, if no timeout happened and the HCD set the URB's status
to ECONNRESET value, the code assumed that a timeout had occured
of usb_unlink_urb() ?
thanks
Franck
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as
David Brownell wrote:
By the way, re the $SUBJECT patch ... is there a bugfix in there,
or is this just trying to be some kind of cleanup?
no there's no fix, only cleanup.
On Wednesday 28 June 2006 12:47 am, Franck Bui-Huu wrote:
It seems that a call to usb_unlink_urb() doesn't always
i dunno why it has still not reached the list...I sent it
6 hours ago.
Original Message
Subject: [RFC] USB subsystem and the BKL
Date: Wed, 28 Jun 2006 10:49:43 +0200
Reply-To: Franck [EMAIL PROTECTED]
To: USB development list linux-usb-devel@lists.sourceforge.net
Hi,
I
This patch uses completion timeout instead of a timer to implement
a timeout when submitting an URB in usb_start_wait_urb().
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/core/message.c | 73 ++--
1 files changed, 30 insertions(+), 43
Franck Bui-Huu wrote:
In devices.c, it's used by usb_device_poll() and usb_device_lseek()
functions.
usb_device_poll():
It seems to use it only to protect usb_device_status
structure. Can't we use a simple mutex here ?
actually I don't think we need a lock at all here
. Can't we use a simple mutex here ?
usb_device_lseek():
can we use the inode's mutex instead ?
In devio.c, it's used by usbdev_open() and usbdev_lseek()
functions. In both function can't we also use the inode's mutex
instead ?
Thanks
Franck
Using Tomcat but need to do more
Oliver Neukum wrote:
Am Montag, 26. Juni 2006 17:34 schrieb Franck Bui-Huu:
It also put the task in interruptible state instead of an
uninterruptible one while waiting for the completion. I'm not
sure about this part though and the comment is not clear.
If someone can confirm that the task
Franck Bui-Huu wrote:
+
+ if (wait_for_completion_interruptible_timeout(
+ done, timeout ? : MAX_SCHEDULE_TIMEOUT) = 0) {
oops, timeout is in ms, and should be converted in jiffies...BTW why not
simply always using jiffies ? timeout value are usually 1s so it's pretty
David Brownell wrote:
On Monday 26 June 2006 9:15 am, Franck Bui-Huu wrote:
So what does this comment try to say ?
/*
* Starts urb and waits for completion or timeout note that this call
* is NOT interruptible, while many device driver i/o requests should
* be interruptible
*/
Maybe
This patch uses completion timeout instead of a timer to implement
a timeout when submitting an URB in usb_start_wait_urb().
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
ok, this function is still uninterruptible and I updated its
comment. It also converts timeout from ms into jiffies
Oliver Neukum wrote:
Am Dienstag, 27. Juni 2006 09:52 schrieb Franck Bui-Huu:
+ expire = timeout ? msecs_to_jiffies(timeout) : MAX_SCHEDULE_TIMEOUT;
+ if (!wait_for_completion_timeout(done, expire)) {
+ usb_unlink_urb(urb);
}
-
+ status = urb-status
Oliver Neukum wrote:
Am Dienstag, 27. Juni 2006 16:09 schrieb Franck Bui-Huu:
Oliver Neukum wrote:
Am Dienstag, 27. Juni 2006 09:52 schrieb Franck Bui-Huu:
+ expire = timeout ? msecs_to_jiffies(timeout) :
MAX_SCHEDULE_TIMEOUT;
+ if (!wait_for_completion_timeout(done, expire
2006/6/27, Alan Stern [EMAIL PROTECTED]:
On Tue, 27 Jun 2006, Franck Bui-Huu wrote:
Franck Bui-Huu wrote:
+
+ if (wait_for_completion_interruptible_timeout(
+ done, timeout ? : MAX_SCHEDULE_TIMEOUT) = 0) {
oops, timeout is in ms, and should be converted in jiffies
This patch uses completion timeout instead of a timer to implement
a timeout when submitting an URB in usb_start_wait_urb()
It also put the task in interruptible state instead of an
uninterruptible one while waiting for the completion. I'm not
sure about this part though and the comment is not
Alan Stern wrote:
On Mon, 26 Jun 2006, Oliver Neukum wrote:
Am Montag, 26. Juni 2006 17:34 schrieb Franck Bui-Huu:
It also put the task in interruptible state instead of an
uninterruptible one while waiting for the completion. I'm not
sure about this part though and the comment is not clear
Hi David,
2006/6/14, David Brownell [EMAIL PROTECTED]:
On Wednesday 07 June 2006 6:11 am, Franck Bui-Huu wrote:
When closing the device, the driver acquires/release twice the
port lock before/after waiting for the data to be completely
sent. Therefore it will dead lock.
This patch
When closing the device, the driver acquires/release twice the
port lock before/after waiting for the data to be completely
sent. Therefore it will dead lock.
This patch fixes it and also uses the generic scheduler services
for waiting for an event.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED
As pointed out by David Brownell, we know that IRQs are never
blocked when calling gs_close function. So the save/restore
IRQ flags are pointless.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/gadget/serial.c | 18 --
1 files changed, 8 insertions(+), 10
ping
Franck Bui-Huu wrote:
When closing the device, the driver acquires/release twice the
port lock before/after waiting for the data to be completely
sent.
It also uses the generic scheduler function for waiting for an
event.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED
When closing the device, the driver acquires/release twice the
port lock before/after waiting for the data to be completely
sent. Therefore it will dead lock.
This patch fixes it and also uses the generic scheduler services
for waiting for an event.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED
Greg KH wrote:
On Tue, Jun 06, 2006 at 10:31:51AM +0200, Franck Bui-Huu wrote:
ping
I was waiting for an ack from the original author of this code. Al, any
comments?
well, thinking more about it, I think the original author wrote its
own wait_event_xxx macros to test the event condition
and use completion timeout instead. It also put the task
in interruptible state instead of an uninterruptible one
while waiting for the completion.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/storage/transport.c | 38 ++
1 files
Alan Stern wrote:
On Wed, 24 May 2006, Franck Bui-Huu wrote:
and use completion timeout instead. It also put the task
in interruptible state instead of an uninterruptible one
while waiting for the completion.
Don't make the email content a continuation of the subject line. When
your
This patch uses completion timeout instead of a timer to implement
a timeout when submitting an URB.
It also put the task in interruptible state instead of an
uninterruptible one while waiting for the completion.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/storage
and use completion timeout instead of. It also put the task
in interruptible state instead of uninterruptible one while
waiting for the completion.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/storage/transport.c | 35 +++
1 files changed
Franck Bui-Huu wrote:
/* wait for the completion of the URB */
- wait_for_completion(urb_done);
- clear_bit(US_FLIDX_URB_ACTIVE, us-flags);
+ timeout = wait_for_completion_interruptible_timeout(
+ urb_done, timeout ? : MAX_SCHEDULE_TIMEOUT
When closing the device, the driver acquires/release twice the
port lock before/after waiting for the data to be completely
sent.
It also uses the generic scheduler function for waiting for an
event.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
well I'm probably missing
Alan Stern wrote:
On Tue, 23 May 2006, Franck Bui-Huu wrote:
Franck Bui-Huu wrote:
/* wait for the completion of the URB */
- wait_for_completion(urb_done);
- clear_bit(US_FLIDX_URB_ACTIVE, us-flags);
+ timeout = wait_for_completion_interruptible_timeout
2006/5/23, Alan Stern [EMAIL PROTECTED]:
On Tue, 23 May 2006, Franck Bui-Huu wrote:
ok but my point is if the US_FLIDX_URB_ACTIVE bit is still set after waiting,
doesn't that mean that the URB doesn't complete normally ? If so we should
call usb_unlink_urb whatever the value of timeout
and use completion timeout instead.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/storage/transport.c | 34 ++
1 files changed, 6 insertions(+), 28 deletions(-)
c35738d918f56fbb725b29c8098cee819e33a83d
drivers/usb/storage/transport.c | 34
.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/misc/usbtest.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
86d3649d27a40ad182ea2f1e0f0edc0177d0ef10
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index ccc5e82..b42ae6b 100644
--- a/drivers
.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/misc/usbtest.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
86d3649d27a40ad182ea2f1e0f0edc0177d0ef10
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index ccc5e82..b42ae6b 100644
--- a/drivers
.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/misc/usbtest.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
32748d5417e7f290dd211db9857c61a65010cc31
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index ccc5e82..b42ae6b 100644
--- a/drivers
wake up since
it's waiting for completion of all urbs.
Do you think that's possible ?
Thanks
--
Franck
---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated
this patch 3 times to make it
reviewed sooner. I'm having some troubles with gmail, and was thinking
that this patch had never reached the mailing list until now. Moreover
the first try was sent yesterday, and the patch just reached the list
now...
sorry for the noise.
Franck
.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/misc/usbtest.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
86d3649d27a40ad182ea2f1e0f0edc0177d0ef10
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index ccc5e82..b42ae6b 100644
--- a/drivers
(request, status = -ERROR);
}
I mean, am I sure that the driver won't queue another request to the queue ?
Thanks
--
Franck
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends
2006/3/23, David Brownell [EMAIL PROTECTED]:
On Monday 20 March 2006 1:50 am, Franck Bui-Huu wrote:
Same question for usb-pullup. Who is supposed to call this method ?
The gadget driver, if it wants to support a mode where it's not always
active. For example, maybe the kernel component
2.6.12-1.1381_FC3, with a uhci HC.
The request was terminated with a EOVERFLOW instead of EREMOTEIO
status, and I don't understand why...can someone bring some light
here ?
Thanks
--
Franck
---
This SF.Net email is sponsored
2006/3/24, Alan Stern [EMAIL PROTECTED]:
On Fri, 24 Mar 2006, Franck Bui-Huu wrote:
This output is very meager.
sorry I forgot to mention that it was snipped. Here is a more complete one:
d5161c80 2492837178 S Co:014:00 -115 0
d5161c80 2492892431 C Co:014:00 0 0
d7aa5180 2492892503 S Ci:014:00
pretty hard to know how things should be done
that is what should be part of the gadget driver or part of the UDC
driver.
Thanks
--
Franck
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends
allocated endpoints whereas the futher call
udc-ep_disable, except for ep0...
What's the rigth thing to do here ? BTW why file_storage driver do not
disable ep0 ?
Same question for usb-pullup. Who is supposed to call this method ?
Thanks
--
Franck
Hi Alan
2006/3/20, Alan Stern [EMAIL PROTECTED]:
On Mon, 20 Mar 2006, Franck Bui-Huu wrote:
I'm wondering who is supposed to release/disable the endpoints which
have been enabled while the usb driver was running. I took a look to 2
different drivers, zero and file_storage drivers
out unrealistic not to retry IN 13.
These lengths are the lengths actually _received_ by the host...
Thanks
--
Franck
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications
2006/3/17, Pete Zaitcev [EMAIL PROTECTED]:
On Fri, 17 Mar 2006 10:54:25 +0100, Franck Bui-Huu [EMAIL PROTECTED]
wrote:
[...]
I'm suprised to see that for the first IN token asking for 36 data
bytes, the host actually received the answer of the second IN token
which is 13 bytes long
--
Franck
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http
There is a dead lock in lh7a40x udc driver. When the driver receive a
SET_FEATURE HALT request, the dev lock is taken by the interrupt
handler lh7a40x_udc_irq then the handler will call lh7a40x_set_halt
function which in its turn will try to acquire the dev lock.
Signed-off-by: Franck Bui-Huu
I noticed a dead lock in lh7a40x udc driver. When the driver receive a
SET_FEATURE HALT request, the dev lock is taken by the interrupt
handler lh7a40x_udc_irq then the handler will call lh7a40x_set_halt
function which in its turn will try to acquire the dev lock.
Thanks
--
Franck
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
drivers/usb/gadget/zero.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
7206a58953a25e6a41d217d8a4e374f15f8dc0db
diff --git a/drivers/usb/gadget/zero.c b/drivers/usb/gadget/zero.c
index ae7a1c0..5e9fe8a 100644
--- a/drivers
,
it's still suspended:
$ cat /sys/bus/usb/devices/.../power/state
3
Am I missing something ?
Thanks
--
Franck
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop
?
I would say usbcore since the bus should know the state of a device
after it was resumed.
Thanks
--
Franck
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new
...
No. You shouldn't call usb_hcd_resume_root_hub() unless your root hub
(i.e., your bus) is suspended.
I put in my resume detect interrupt handler :
if (hcd-state == HC_STATE_SUSPENDED)
usb_hcd_resume_root_hub(hcd);
Is that correct ?
Thanks
--
Franck
?
It's correct if and only if hcd-state behaves properly. Note that
hcd-state can be set by code outside of your driver, so it's not totally
reliable.
Well if hcd-state does not behave properly that means something is
broken in the core layer, isn't it ?
Thanks,
--
Franck
() and raise C_PORT_SUSPEND
flag when getting the remote wakeup interrupt ?
Thanks
--
Franck
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine
new year,
--
Franck
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web
2005/12/19, Alan Stern [EMAIL PROTECTED]:
On Mon, 19 Dec 2005, Franck wrote:
The new code is supposed to work okay, even with values between 0 and 500.
If it doesn't, maybe Franck has found a real problem with it.
setting hcd-power_budget to 0 (meaning power budget illimeted) fixes
2005/12/19, Alan Stern [EMAIL PROTECTED]:
On Mon, 19 Dec 2005, Franck wrote:
BTW, the hcd suspend method do:
dev-dev.power.power_state = state;
I think this work should be part of the driver model, shouldn't it ?
No. The driver core does not understand the power states any
method do:
dev-dev.power.power_state = state;
I think this work should be part of the driver model, shouldn't it ?
Thanks
--
Franck
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
Hi Olav
2005/12/17, Olav Kongas [EMAIL PROTECTED]:
On Fri, 16 Dec 2005, Alan Stern wrote:
On Fri, 16 Dec 2005, Franck wrote:
Hi Alan,
2005/12/15, Alan Stern [EMAIL PROTECTED]:
No, the bus should already be suspended. In fact, you should fail the
driver-suspend
2005/12/17, Alan Stern [EMAIL PROTECTED]:
On Fri, 16 Dec 2005, Franck wrote:
No, that's not what it means. Suspending all the devices attached to a
bus is different from suspending the bus itself.
Well stopping any activity on the bus (that's what happen when
suspending all
2005/12/17, Olav Kongas [EMAIL PROTECTED]:
On Fri, 16 Dec 2005, Franck wrote:
2005/12/16, Alan Stern [EMAIL PROTECTED]:
By definition every host controller, including yours, has a root hub.
That one port is the root hub's downstream port.
The point of a bus suspend
Device
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 2mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=05 Prot=50 Driver=usb-storage
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
Thanks
--
Franck
2005/12/16, Alan Stern [EMAIL PROTECTED]:
On Fri, 16 Dec 2005, Franck wrote:
OK, I think I get the main idea of suspend/resume process for usb. But
now, I don't see the purpose of hcd-bus_suspend method. What is it
supposed to do since all of its children must be suspended (meaning
because the way sl811 and isp116
implement suspend are different...
Thanks
--
Franck
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine
OK.
Though you freeze your system during 7ms. Why not sleeping instead
with INT enable ?
Thanks
--
Franck
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new
Hi,
I'm looking at suspend/resume code and I run into
isp116x_bus_suspend function. It seems buggy because if the hcd is
transfering URB the function wait for it to finish. But it waits with
IT disabled...is that correct ?
Thanks
--
Franck
2005/10/25, Alan Stern [EMAIL PROTECTED]:
On Tue, 25 Oct 2005, Franck wrote:
I noticed in hcd_submit_urb that we increments the reference count of
the usb device structure through usb_get_dev. This refence count seems
to be handle by usbcore, is that correct ?
The reference count can
2005/10/24, Alan Stern [EMAIL PROTECTED]:
On Fri, 21 Oct 2005, Franck wrote:
But the HCD can decide to not add the urb into the ep's queue if
something is going wrong...In that case it refuses to own the urb.
What I was thinking of is: the usbcore initialized the urb then passes
).
The second point is that hcd can't easily parse ep's queue because
this queue is protected by a private usbcore's lock.
fix: we can export usbcore lock.
What do you think ?
Thanks
--
Franck
---
This SF.Net email is sponsored
the kernel
can lost so many ticks.
Could anyone give me some advices for that ?
Thanks
--
Franck
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http
2005/10/21, Alan Stern [EMAIL PROTECTED]:
On Fri, 21 Oct 2005, Franck wrote:
Alan, David
Sorry for responding so late but I was off until now. We recenlty
discussed about 2 issues that I encoutered when developping an HCD.
Here is the sum up of the 2 points:
First point, when
by
(a) calling hcd-urb_dequeue method (b) kfreeing urbDon't we need
to remove the urb from ep's queue somewhere before the queue is
rescaned from the start ?
Thanks
--
Franck
---
This SF.Net email is sponsored by:
Power
2005/10/13, Alan Stern [EMAIL PROTECTED]:
On Thu, 13 Oct 2005, Franck wrote:
obviously endpoint queues are usbcore's data but used by hcd. hcd
seems to know when an urb is active. Therefore we could export a new
usbcore's function which would be called by hcd to make an urb active
the queue's lock is private to usbcore. In my case the queue should be
managed by the HCD and parsed by usbcore.
Thanks
--
Franck
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads
2005/10/12, Alan Stern [EMAIL PROTECTED]:
On Wed, 12 Oct 2005, Franck wrote:
Does a patch that do this have any chance to be accepted ?
I think we should decide on the _correct_ solution first. Then acceptance
will be obvious.
ok, but my question was more: does the usbcore need
usb_hos_endpoint *ep, struct *urb)
{
spin_lock(hcd_data_lock);
usb_get_urb(urb);
atomic_inc(urb-use_count);
list_add_tail (urb-urb_list, ep-urb_list);
spin_unlock(hcd_data_lock);
}
Thanks
--
Franck
it can't happen. Allocation happens only when scheduling
an ep the first time. At this time this ep in not in my list of active
ep so it's not a candidate for transfering URB.
So your urb_enqueue method can never fail, except on the first URB for an
endpoint?
Yes.
Thanks
--
Franck
2005/10/12, Alan Stern [EMAIL PROTECTED]:
On Wed, 12 Oct 2005, Franck wrote:
Remember that the only data protected by urb-lock is urb-status,
urb-urb_list, and urb-reject. Your HCD should change nothing but the
status.
it also changes hcpriv, actual_length, interval, start_frame
2005/10/12, Alan Stern [EMAIL PROTECTED]:
On Wed, 12 Oct 2005, Franck wrote:
A simple fix is to link urb right after
calling hcd-urb_enqueue. What do you think about this ?
Not good. The URB must be linked before the HCD is called. Your idea
runs the risk of the opposite
the same in my hcd ?
Thanks
--
Franck
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
because I get sometime a warning on the
console saying:
Badness in kref_get at lib/kref.c:32.
Thanks
--
Franck
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more
2005/10/11, Alan Stern [EMAIL PROTECTED]:
On Tue, 11 Oct 2005, Franck wrote:
2005/10/11, Alan Stern [EMAIL PROTECTED]:
Be more careful here. It doesn't hold urb-lock while _reading_
urb-status; there's no point. But it does hold urb-lock while
_writing_ urb-status
--
Franck
---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
linux
Hi Alan.
2005/10/10, Alan Stern [EMAIL PROTECTED]:
On Mon, 10 Oct 2005, Franck wrote:
But sometime this field is NULL when starting an URB transfer ! That's
normally impossible since _all_ URBs submitted to an HCD use
hcd-urb_enqueue, isn't it ?
Could someone help me on this point
?
Thanks.
--
Franck
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP. Click here to play
.
--
Franck
2005/9/20, Alan Stern [EMAIL PROTECTED]:
On Tue, 20 Sep 2005, Franck wrote:
Hi,
I'm still debuging this [EMAIL PROTECTED] HCD. Hardware causes me a lot of
troubles. Anyways, I have noticed that if I plug a usb device before
booting, then HC's IRQ are not handled
, the device
configuration fails ! Still because of data error. The only difference
is that the hcd is running faster...
Thanks
--
Franck
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x1 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage
; mount -t vfat /dev/sda1 /mnt
unfortunately I get : No such device or address...
Does anybody have a hint to mount it ?
Thanks.
--
Franck
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App
Hi Alan
Acutally every drivers scsi_mod, sd_mod, and usb-storage are built in
the kernel. BTW, does that mean hotplug thing is useless ? I added
some traces in the driver, I attached them. Does the communication
look good to you ?
Thanks.
--
Franck
minicom.cap
Description
2005/9/15, Alan Stern [EMAIL PROTECTED]:
On Thu, 15 Sep 2005, Franck wrote:
Hi Alan
Acutally every drivers scsi_mod, sd_mod, and usb-storage are built in
the kernel. BTW, does that mean hotplug thing is useless ? I added
some traces in the driver, I attached them. Does
2005/9/15, Alan Stern [EMAIL PROTECTED]:
On Thu, 15 Sep 2005, Franck wrote:
OK, I didn't added SCSI disk support in my kernel. It's not
automatically selected when selecting USB mass storage driver, is
there any reasons ?
Yes. USB mass storage devices need not be disk drives. You
1 - 100 of 119 matches
Mail list logo
