David Brownell wrote:
I'll include it; there's another patch of Alex's that I want to
test too (for a problem Al Borchers reported, and I think
I've probably seen too -- system hang).
I finally found some time to test out Alex's patch. It fixed the
problem I was seeing. I as able to disconnect/re
Hi Alan,
the message "HC died; cleaning up" does indeed still appear in 2.6.9-rc1:
Sep 14 03:59:42 noisy kernel: ehci_hcd :00:1d.7: EHCI Host Controller
Sep 14 03:59:42 noisy kernel: ehci_hcd :00:1d.7: irq 12, pci mem e088ac00
Sep 14 03:59:42 noisy kernel: ehci_hcd :00:1d.7: new USB
On Monday 13 September 2004 2:25 pm, Alan Stern wrote:
> On Fri, 10 Sep 2004, Alex Sanks wrote:
> It does the job for me too, thanks.
>
> David, would you like to call this to Greg's attention? Or include it
> in one of your batches?
I'll include it; there's another patch of Alex's that I want
--- Lothar Wassmann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Michael Moedt writes:
> > Hi guys.
> >
> > I've been following your recent posts on linux-usb-devel.
> > I am also working with the ISP1362 chip, and I'm at the
> > point where I'd like to either port an existing 2.4 driver
> > to 2.6 or
On Fri, 10 Sep 2004, Alex Sanks wrote:
> Ok, found it. It turns out that this was caused by my update a while back for
> compliance testing (a customer was seeing a glitch during HS electrical testing
> caused by the pullups being toggled during a root port reset). It seems the
> unregister c
Greg:
This patch repairs a mistake I made when adding OTG support to the
file-storage gadget. All the descriptor entries were bumped up by one,
which caused a problem during initialization.
Please apply.
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
= drivers/usb/gadget/fil
Greg:
This patch adds support for calling usb_reset_device() on hubs (other than
root hubs). It uses some of the new routines added recently by David
Brownell to shorten and simplify the code. The only place where this is
called is if khubd encounters a serious error with a hub, so I don't
expec
Hi,
sending a separate patch for ftdi_sio.c.
Description:
corrected handling when unlinking read URB's, that were synchronous
- usb_kill_urb() is used from now on.
Thanks for applying,
Jan
Jan Capek - CCS Inc.
Firmware developer
Signed-off-by: Jan Capek <[EMAIL PROTECTED]>
--
Hi,
sending a separate patch for usb-serial.c.
Description:
- corrected handling when unlinking read URB's, that were synchronous,
usb_kill_urb() is used from now on.
- removed unnecessary checks for NULL, as those are handled internally
by the usb framework
Thanks for applying,
Jan
Jan Capek
Greg:
Here is an up-to-date straightened-out version of as364. Please apply it,
using the Changeset comments from the previous email at
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=109485484218227&w=2
Alan Stern
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
# This is a BitKeeper gener
On Fri, 10 Sep 2004, Greg KH wrote:
> Hm, this still doesn't apply:
> patching file drivers/usb/core/hcd.c
> Hunk #2 FAILED at 1594.
> 1 out of 2 hunks FAILED -- saving rejects to file drivers/usb/core/hcd.c.rej
> drivers/usb/core/hub.c 1.198: 2851 lines
> patching file drivers/usb/core/hub.c
> H
On Monday 13 September 2004 1:29 pm, Alan Stern wrote:
>
> Do you have a clear idea of exactly what is supposed to get accomplished,
> and how much is supposed to happen in_interrupt in the HCD as opposed to
> later on in khubd? I don't. Getting the design straight would be my
> first step.
The
On Mon, 13 Sep 2004, David Brownell wrote:
> The caller of hc_died() -- an HCD -- should reset the root hub
> as part of recovery, which should leave traces that khubd
> can find and clean up after.
> Maybe this should just be a root hub API, not an HCD API.
> Could be. Though maybe khubd shoul
Am Montag, 13. September 2004 21:27 schrieb Linas Vepstas:
> Another alkternative to returning -ENODEV is to have a zero-length read.
> This is a traditional unix way of signifying that the remote end has
> disconnected; e.g. for tcp sockets. That is, select() will tell you
> that there is somethi
Hi,
Michael Moedt writes:
> Hi guys.
>
> I've been following your recent posts on linux-usb-devel. I am also
> working with the ISP1362 chip, and I'm at the point where I'd like to
> either port an existing 2.4 driver to 2.6 or do something similar to
> the SL811 driver, but for the ISP chip.
>
Hi,
Dimitris Lampridis writes:
> Yes, but from what I've seen in your code, there is a Memory I/O region
> that you ioremap to dev->data_reg and dev->addr_reg. In my case, there
> is an I/O port (let's say for example address 0x200) and I must do:
> data_reg=0x200, addr_reg=data_reg + 2. Is there
These new entries may be fixed/added to the list of "multimedia
device" drivers available at http://www.linux-usb.org/devices.html:
TypeStatus MaintainerWhere to find
-- ---
W996[87]CF Working Luca Risolia kernel, http://go.lamarinapunto.c
Hi,
> I looked through the ohci-isp1362.h (thanks Dimitris for
> forwarding it) and compared the register layout with the one
> needed for 1160. Indeed the match is very good and it would
> suffice to add the definitions of just few registers (0x2d,
> 0x2e, and 0x41) to cover also 1160. Didn't mak
On Sun, Sep 12, 2004 at 04:33:13AM +0400, Alexander N. Kozhushkin was heard to remark:
>
> Unfortunately, now I cannot present a full list of device drivers
> which use the first and second approaches. However, the
> "drivers/input/mousedev.c" file by Vojtech Pavlik is an e
On Monday 13 September 2004 9:13 am, Alan Stern wrote:
> [ about the hc_died() cleanup ]
>
> It's not at all clear to me how that will accomplish what the code used to
> do, i.e., disconnecting all the root hub's children.
That old code didn't quite work right in any case ... :)
The caller
Hi guys.
I've been following your recent posts on linux-usb-devel. I am also
working with the ISP1362 chip, and I'm at the point where I'd like to
either port an existing 2.4 driver to 2.6 or do something similar to
the SL811 driver, but for the ISP chip.
I understand that you are currently in t
SN9C10x driver updates.
Changes: (+ new, - removed, * cleanup, @ bugfix, = sync with kernels)
@ Create correct red,green,blue entries under /sys according to the detected
bridge
* Add and use defined symbols for I2C slave ids of TAS5110C1B and TAS51130D1B
* Color fixes for PAS202BCB - from its
David:
Your patch leaves usb_hc_died() looking like this:
void usb_hc_died (struct usb_hcd *hcd)
{
dev_err (hcd->self.controller, "HC died; cleaning up\n");
/* make khubd clean up old urbs and devices */
usb_set_device_state(hcd->self.root_hub, USB_STATE_NOTATTACHED);
On Mon, 13 Sep 2004, Toralf Lund wrote:
> Actually, I was wrong. I still get the resets, and I also have
>
> Sep 13 16:00:42 indonesia kernel: usb.c: USB disconnect on device
> 00:11.0-2 address 4
>
> or similar in the system log.
>
> *SIGH!* This one is really hard to track down :-(
Hardware
On Mon, 13 Sep 2004, Yannick Beynet wrote:
> i used this udev rule for my iomega key (128Mo) :
>
> BUS="usb", SYSFS{serial}="020283163800D225", NAME="cleusb%n"
>
> /dev/cleusb is always created, but /dev/cleusb1 is not (sometimes).
>
> If I plug my key directly on my computer (not on the extern
On Sun, 12 Sep 2004, Johannes Erdfelt wrote:
> > In short, your USB host controller has a hardware bug. It's supposed to
> > advance the QH element pointer whenever a TD completes successfully by
> > copying the TD's link pointer into the element pointer. But it didn't do
> > that when TD 0 f
On Mon, 13 Sep 2004, Ian Abbott wrote:
> FWIW, the ftdi_sio change looks okay by me, assuming you've tested
> it. (I haven't tested it myself yet and don't know much about
> usb_kill_urb, but if that's the way to go, then so be it!)
Here's a quick explanation of usb_kill_urb for anyone who's i
Toralf Lund wrote:
Alan Stern wrote:
On Thu, 9 Sep 2004, Toralf Lund wrote:
Something I forgot to mention earlier: I often see evidence of reset
signalling at the point where the problems occurs. Could that be
something initiated by the host/driver? If it is, how am I supposed
to respond?
Hi,
this implements a work around for some devices which have correct
extra descriptors, but misplace them.
Regards
Oliver
Signed-Off-By: Oliver Neukum <[EMAIL PROTECTED]>
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repos
On 13/09/2004 13:48, Jan Capek wrote:
That race condition is exactly what I was talking about. Since it's bound
to be pretty rare, there's probably no harm in displaying the error
message. But it also wouldn't hurt to check for result != -EPERM. It's
your choice.
Alan Stern
I think, it's better
Hi,
> > I also checked, how the read URB's are resubmitted, the logic in the
> > driver is correct. The upper layer (usb-serial.c) calls ftdi_close, only
> > when the port->open_count <= 0. The function ftdi_process_read(), that is
> > issued by the completion handler (ftdi_read_bulk_callback()), t
I looked through the ohci-isp1362.h (thanks Dimitris for
forwarding it) and compared the register layout with the one
needed for 1160. Indeed the match is very good and it would
suffice to add the definitions of just few registers (0x2d,
0x2e, and 0x41) to cover also 1160. Didn't make bit
comparis
On Fri, 2004-09-10 at 16:56, Lothar Wassmann wrote:
> > And a few more questions to be able to understand what is left to be
> > done to port the ISP1160 to your driver style:
> > 1) your SL811 is memory-mapped? This is my main problem in immitating
> >
> No. The SL811 has the same interface as the
On Mon, 2004-09-13 at 09:59, Olav Kongas wrote:
> Hi Lothar,
>
> On Sat, 11 Sep 2004, Dimitris Lampridis wrote:
>
> > On Fri, 2004-09-10 at 16:56, Lothar Wassmann wrote:
> > > No. The device could be used as a slave DMA device, but:
> > > 1) in our hardware the data register is located on a non
Alan Stern wrote:
On Thu, 9 Sep 2004, Toralf Lund wrote:
Something I forgot to mention earlier: I often see evidence of reset
signalling at the point where the problems occurs. Could that be
something initiated by the host/driver? If it is, how am I supposed to
respond?
The USB core will
Hi Lothar,
On Sat, 11 Sep 2004, Dimitris Lampridis wrote:
> On Fri, 2004-09-10 at 16:56, Lothar Wassmann wrote:
> > No. The device could be used as a slave DMA device, but:
> > 1) in our hardware the data register is located on a non-DMAable
> > address (PXA DMA addresses must be aligned t
36 matches
Mail list logo
