On Thu, 07 Apr 2005 09:02:57 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > Interesting. Looks like pci_enable_wake(dev, state, 0) isn't
> > actually disabling wakeup on your hardware. (Assuming
> > CONFIG_USB_SUSPEND=n; if not, then it's odd that the system went
> > back to sleep!)
On Wed, 6 Apr 2005 13:11:53 -0700
David Brownell <[EMAIL PROTECTED]> wrote:
> Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually
> disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if
> not, then it's odd that the system went back to sleep!)
Yes, CONFIG_USB_
Christopher Li wrote:
> I am a long time happy quilt user.
Took me a while to find the quilt home page... there's a lot of software
out there called quilt.
Quilt looks pretty neat to me...
Greg, any reason you picked quilt over the other various alternatives?
Personally I like systems based arou
On Thu, 07 Apr 2005 01:50:25 +0100 Andrew Marshall <[EMAIL PROTECTED]> wrote:
> The device is properly unmounted and file handles etc. closed at removal by
> code invoked by hotplug.
My first instinct is to doubt the above. But yes, it can be a bug, too.
If so, I don't think it's specific to USB.
On Wednesday 06 April 2005 4:50 pm, Benjamin Herrenschmidt wrote:
> On Wed, 2005-04-06 at 16:28 -0700, David Brownell wrote:
> > On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote:
> > >
> > > > Thanks for the testing update. I'm glad to know that there seems to
> > > > be only one
Hi All,
I would be very grateful for any advice any of you guys may have on the
following: -
I am running Kernel version 2.4.22 (uClinux distribution -- i'm currently
unable to upgrade for various reasons...).
I've found that when removing a USB flash key device during a file read,
once the devi
I am a long time happy quilt user.
On Wed, Apr 06, 2005 at 02:26:08PM -0700, Greg KH wrote:
>
> I realize this isn't the best way to handle this so far, and I know it
> isn't workable. I'm thinking of doing something like the following:
>
> - provide raw quilt directory of patches (like t
On Wed, 2005-04-06 at 16:28 -0700, David Brownell wrote:
> On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote:
> >
> > > Thanks for the testing update. I'm glad to know that there seems to
> > > be only one (minor) glitch that's PPC-specific!
> >
> > Which is just an off-the-shelve
On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote:
>
> > Thanks for the testing update. I'm glad to know that there seems to
> > be only one (minor) glitch that's PPC-specific!
>
> Which is just an off-the-shelves NEC EHCI chip.
The wakeup-after-suspend hasn't been reported by an
> Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually
> disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if
> not, then it's odd that the system went back to sleep!) Do you think
> that might be related to those calls manipulating the Apple ASICs being
> in t
On Wed, Apr 06, 2005 at 02:54:02PM -0700, David Brownell wrote:
> On Wednesday 06 April 2005 2:26 pm, Greg KH wrote:
>
> > I'm thinking of doing something like the following:
> >
> > - provide raw quilt directory of patches (like the directory
> > above has in it.)
> > - nightly pr
On Wednesday 06 April 2005 2:26 pm, Greg KH wrote:
> I'm thinking of doing something like the following:
>
> - provide raw quilt directory of patches (like the directory
> above has in it.)
> - nightly provide a patch against the latest kernel tree for the
> different
On Wed, Apr 06, 2005 at 04:58:24PM -0400, Alan Stern wrote:
> On Wed, 6 Apr 2005, Greg KH wrote:
>
> > As per the comments about BitKeeper on lkml, I will not have a usb bk
> > tree anymore. I've switched over to using quilt, and will expose that
> > patchset for everyone to see in some form so t
On Wed, 6 Apr 2005, Greg KH wrote:
> As per the comments about BitKeeper on lkml, I will not have a usb bk
> tree anymore. I've switched over to using quilt, and will expose that
> patchset for everyone to see in some form so that people can keep up to
> date with my tree. An initial dump of the
On Tuesday 05 April 2005 11:01 am, Olav Kongas wrote:
> Hi,
>
> I am trying to get rid of sparse's bitwise warnings in my
> isp116x-hcd driver. Regardless of studying the explanations
> about __bitwise, as for example in
> http://kerneltrap.org/node/3848 I was still not able to get
> rid of al
On Wednesday 06 April 2005 10:20 am, Colin Leroy wrote:
> On 05 Apr 2005 at 13h04, David Brownell wrote:
> > >
> > > What kind of work on these is needed so that they get in?
> >
> > Briefly, given 2.6.12-rc2 plus the patches mentioned above,
> > find out what else is needed.
> > ...
> > How's th
On 06 Apr 2005 at 12h04, David Brownell wrote:
Hi David,
> - Mostly updates the power switching on EHCI controllers. One
> routine centralizes the "power on/off all ports" logic, and the
> capability to do that is reported more correctly.
>
> - Courtesy Colin Leroy, a patch to always power u
Here's the promised update for EHCI port power switching.
- Dave
Miscellaneous updates for EHCI.
- Mostly updates the power switching on EHCI controllers. One routine
centralizes the "power on/off all ports" logic, and the capability to
do that is reported more correctly.
- Courtesy Co
On Wednesday 06 April 2005 11:29 am, Duncan Sands wrote:
> Thanks for replying David.
>
> > > > When a driver gets a disconnect(interface) call, it must stop using
> > > > all those references ... though it's just barely OK to drop such
> > > > a reference (with the also-not-exported usb_put_intf!
On Wed, 6 Apr 2005, James Lamanna wrote:
> On Apr 5, 2005 8:47 AM, Alan Stern <[EMAIL PROTECTED]> wrote:
> > On Mon, 4 Apr 2005, James Lamanna wrote:
>
>
>
> Thanks for the previous replies, I think I've got device setup all working.
> The USB device is now registered as a HID Joystick (with 1
On Wed, 6 Apr 2005, Thomas Brinker wrote:
> Hello!
>
> I'd like to send in an patch to add support for fhg_usb32
> USB-Client-Controller.
>
> It passes every test from http://www.linux-usb.org/usbtest/index.html#gadgets
> and also the USBCV from usb.org
>
> I can also ping via g_ether.
>
> B
On Wed, 6 Apr 2005, Duncan Sands wrote:
> Hi Alan, thanks for the info.
>
> > If you want to be able to use a pointer to the interface, then
> > usb_get_intf is what you need. But of course you shouldn't do anything
> > significant (like sending an URB to the interface) once it's a zombie.
>
>
Thanks for replying David.
> > > When a driver gets a disconnect(interface) call, it must stop using
> > > all those references ... though it's just barely OK to drop such
> > > a reference (with the also-not-exported usb_put_intf!) after that
> > > disconnect() returns.
> >
> > I know this has a
> I'm still waiting
> for the
> response from Philips about this point. As soon as I get it,
> we'll decide
> what to do. So far we have two options:
>
> 1) start from the driver for 116x and add support for 1362 as
> described here:
> http://sourceforge.net/mailarchive/message.php?msg_id=1088026
On Wednesday 06 April 2005 10:28 am, Duncan Sands wrote:
> Hi David,
>
> > When a driver gets a disconnect(interface) call, it must stop using
> > all those references ... though it's just barely OK to drop such
> > a reference (with the also-not-exported usb_put_intf!) after that
> > disconnect()
On Wed, Apr 06, 2005 at 07:28:27PM +0200, Duncan Sands wrote:
> > On Sunday 03 April 2005 8:33 am, Duncan Sands wrote:
> > > Suppose a driver has taken a reference to a usb device (usb_get_dev).
> > > Can the list of interfaces shift around underneath it? For example,
> > > suppose the configurati
Hi Alan, thanks for the info.
> If you want to be able to use a pointer to the interface, then
> usb_get_intf is what you need. But of course you shouldn't do anything
> significant (like sending an URB to the interface) once it's a zombie.
Do you mean "mustn't do anything significant", or do y
Hi David,
> On Sunday 03 April 2005 8:33 am, Duncan Sands wrote:
> > Suppose a driver has taken a reference to a usb device (usb_get_dev).
> > Can the list of interfaces shift around underneath it? For example,
> > suppose the configuration changes, changing the set of interfaces.
>
> Yes, exact
On 05 Apr 2005 at 13h04, David Brownell wrote:
Hi,
> > There are known issues with USB after suspend/resume (D3 hot) on
> > powerpc.
>
> Also known fixes to some of them, which haven't yet been merged.
> I'll repost these as followups to this message, to linux-usb-devel
> and CC Colin. They're
On Wed, 6 Apr 2005, Carlos Martin wrote:
> On Apr 6, 2005 5:41 AM, Patrick Mochel <[EMAIL PROTECTED]> wrote:
> > Carlos, could you try this patch and let me know if it helps?
> The patch works! The computer survives now. However, it says that it
> failed with error 0, which I don't think is actu
As per the comments about BitKeeper on lkml, I will not have a usb bk
tree anymore. I've switched over to using quilt, and will expose that
patchset for everyone to see in some form so that people can keep up to
date with my tree. An initial dump of the tree is at:
http://www.kernel.org/p
On Apr 6, 2005 5:41 AM, Patrick Mochel <[EMAIL PROTECTED]> wrote:
> Carlos, could you try this patch and let me know if it helps?
The patch works! The computer survives now. However, it says that it
failed with error 0, which I don't think is actually an error.
--
Carlos MartÃn http://ww
On Apr 5, 2005 8:47 AM, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Apr 2005, James Lamanna wrote:
Thanks for the previous replies, I think I've got device setup all working.
The USB device is now registered as a HID Joystick (with 1 axis for
the moment) and it has 1 interrupt IN endpoint.
> Thanks for your cooperation.
> In the meanwhile we successfully ported the Philips host
> controller driver to our custom hardware and we achieved a
> transfer rate of 670 kB/s when reading a 32 MB memory stick
> (with old driver we achieved 64 kB/s, so it improved one
> order of magnitude
Am Mittwoch, 6. April 2005 16:28 schrieb Kresimir Peharda:
>
> --- Oliver Neukum <[EMAIL PROTECTED]> wrote:
> >
> > Did it work with exactly this kernel on the old motherboard?
> > Try something like
> > "dd if=/dev/sda of=/dev/null" to rule out filesystem involvement.
> > A 32MB might indicate a
Hi Jordan,
Sorry about that last blank email.
no problem.
I have recently been working
with the ISP1362 HC driver from DENX Software to attempt to make the
bulk transfers faster. However, I have been unsuccessful with it so
far. If you would like a copy of what I have at this point, I can
llandre,
> I'm working with ISP1362 on some PPC405EP-based embedded
> platforms. So far I used the drivers included in the 2.4.20
> tree hosted at Denx Software Engineering. As host controller
> driver is not able to exploit all the available bandwidth for
> bulk transfers (for example see thi
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of llandre
> Sent: Wednesday, April 06, 2005 6:27 AM
> To: Michael
> Cc: linux-usb-devel@lists.sourceforge.net
> Subject: Re: [linux-usb-devel] Original drivers for ISP1362 by Philips
>
>
> Hi Mike,
Hi Alan,
> Of course. The partition _can't_ be removed if it's actively in use, as a
> result of being mounted.
OK.
> It's not clear why the block device file is deleted when the card is
> removed and the partition isn't mounted. The kernel itself doesn't know
> when cards are removed from rea
Hi Mike,
thanks a lot for your answers.
The licensing model is clearly very important and I did not
realized they are not under GPL (when one gets used to work with tons of
open source software, sometimes assumes by default that all the sources are
covered by this license ...).
I'm getting in touch
On Wed, 06 Apr 2005, Roman Kagan wrote:
> On Wed, Apr 06, 2005 at 11:34:16AM +0200, maximilian attems wrote:
> > On Wed, 06 Apr 2005, Duncan Sands wrote:
> > > > Apr 5 12:07:30 sputnik kernel: usb 1-1: USB disconnect, address 7
> > > > Apr 5 12:07:30 sputnik kernel: usb_unlink_urb() is deprecate
On Wed, Apr 06, 2005 at 11:34:16AM +0200, maximilian attems wrote:
> On Wed, 06 Apr 2005, Duncan Sands wrote:
> > > Apr 5 12:07:30 sputnik kernel: usb 1-1: USB disconnect, address 7
> > > Apr 5 12:07:30 sputnik kernel: usb_unlink_urb() is deprecated for
> > > synchronous unlinks. Use usb_kill_u
On Wed, 06 Apr 2005, Duncan Sands wrote:
> Hi Maximilian,
>
> > having fun playing with firmware loading i discovered:
> >
> > Apr 5 12:07:30 sputnik kernel: usb 1-1: USB disconnect, address 7
> > Apr 5 12:07:30 sputnik kernel: usb_unlink_urb() is deprecated for
> > synchronous unlinks. Use
Hi Maximilian,
> having fun playing with firmware loading i discovered:
>
> Apr 5 12:07:30 sputnik kernel: usb 1-1: USB disconnect, address 7
> Apr 5 12:07:30 sputnik kernel: usb_unlink_urb() is deprecated for
> synchronous unlinks. Use usb_kill_urb() instead.
thanks for this. In fact it's
Am Mittwoch, 6. April 2005 03:39 schrieb Andrew Morton:
>
> Guys, is this a USB problem?
[..]
> Steps to reproduce:
> Put a card in a reader and hook it up to the USB. If 32MB card is in it (can
> also be inserted later) it works. Attempts with 64M and 256M cards fail. Tried
> other kernels too (
45 matches
Mail list logo
