> > A driver on a 64bit system with a 32bit host controller, if the system
> > has more than 4GB of RAM.
>
> By the time such systems become problematic, I'd expect hardware
> vendors would be phasing out such 32bit I/O controllers. Remember
> they're mostly integrated on motherboards.
You are r
On Thu, 3 Jan 2002, Greg KH wrote:
> On Thu, Jan 03, 2002 at 08:23:44PM -0500, Pete Zaitcev wrote:
> > > Here's a patch against 2.5.2-pre7 that allows the USB core to control
> > > the module usage count of the USB driver modules.
> >
> > Looks good, but one question - was it oopsable before?
>
>
On Thu, 3 Jan 2002, David Brownell wrote:
> Now I'm not following _you_ ... could you give an example of
> what you mean?
A driver on a 64bit system with a 32bit host controller, if the system
has more than 4GB of RAM.
> In my proposal, device drivers would be able to either use
> the current r
On Thu, 3 Jan 2002, Greg KH wrote:
> On Thu, Jan 03, 2002 at 10:33:55AM +0100, [EMAIL PROTECTED] wrote:
> >
> > Regarding devio.c, specifically proc_ioctl().
> > How is it ensured that the ps->dev pointer stays valid although the memory
> > allocations might sleep ?
>
> That's a good question, bu
> > > > On 64Bit machines we might have to deal with HCDs who can do 32Bit DMA
> > > > only. Perhaps there should be a gfp field in the usb_device struct
> > > > to export knowledge about the memory the HCD can cope with.
> > >
> > > Shouldn't be needed.
> >
> > How do we deal with the combination
On Wed, 2 Jan 2002, Greg KH wrote:
> On Wed, Dec 19, 2001 at 10:31:31AM +0100, [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > this adds module usage count handling during probe and disconnect to the
> > usb core. It applies to 2.5.1 and is now in the smallest possible form.
> > I did not go at the old
On Wed, 2 Jan 2002, Jens Axboe wrote:
> On Wed, Jan 02 2002, David Brownell wrote:
> > > > requirement for drivers is that the transfer buffers can be passed to
> > > > pci_map_single() calls by the Host Controller Drivers (HCDs). The
> > > > device drivers, and URBs, don't expose such mappings,
On Wed, 2 Jan 2002, David Brownell wrote:
> > > > I presume there is some overhead in bouncing to lowmem? I imagine that
> > > > highmem support for the HCDs wouldn't be that difficult -- they are just
> > > > PCI devices, after all.
> > >
> > > I'm unclear on what "bouncing to lowmem" involves,
> - EITHER:
>
> * each HCD is modified to manage page DMA
> mappings if needed, in the same places they now
> handle the single shot DMA mappings
>
> - OR:
>
> * the (new) hcd layer does this, once. In that case
> it'd be advantageous to add
> > I presume there is some overhead in bouncing to lowmem? I imagine that
> > highmem support for the HCDs wouldn't be that difficult -- they are just
> > PCI devices, after all.
>
> I'm unclear on what "bouncing to lowmem" involves, but I'd rather avoid
> teaching all three HCDs a second model
> 1. What's the difference between usbdevfs and devfs? Is there a way of
> searching the /proc/bus/usb directory for a file entry (driver) that manages
> a certain device (by checking its vendor and product id)?
Usbdevfs is a file system for getting information about usb devices and
user space dr
On Sun, 30 Dec 2001, Nick Craig-Wood wrote:
> I'm sure this is a known problem - does anyone know how to go about
> fixing it?
Please go to the syslog and check whether usb-storage computes identical
UUIDs for both devices.
Regards
Oliver
_
> > I don't think it _can_ go away. Among other things, driver
> > frameworks layered on top of USB (say, usb-serial :) need
> > to rely on it, since the device-specific code isn't what's
> > managing all the probe() calls.
>
> Exactly. It will not go away.
>
> Oliver, can you redo your patch an
> > > What do you mean "old style probe"?
> >
> > The special casing for drivers that don't supply an id_table.
> > IMHO it should go away.
>
> I don't think it _can_ go away. Among other things, driver
> frameworks layered on top of USB (say, usb-serial :) need
> to rely on it, since the device-
On Fri, 21 Dec 2001, David Brownell wrote:
> > > But the drivers' ID tables are part of the module ...
> > > what's the locking being done to prevent rmmod
> > > during the usb_match_id() call?
> >
> > On 2.5 it is protected, once the module subsystem patches are in, by
> > usb_match_id() not sle
On Wed, 19 Dec 2001, Greg KH wrote:
> On Wed, Dec 19, 2001 at 10:31:31AM +0100, [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > this adds module usage count handling during probe and disconnect to the
> > usb core. It applies to 2.5.1 and is now in the smallest possible form.
> > I did not go at the old
On Wed, 19 Dec 2001, David Brownell wrote:
> But the drivers' ID tables are part of the module ...
> what's the locking being done to prevent rmmod
> during the usb_match_id() call?
On 2.5 it is protected, once the module subsystem patches are in, by
usb_match_id() not sleeping.
As this patch is
On Wed, 19 Dec 2001, Ken Hahn wrote:
> *breathing deeply*
>
> Ok, I'm just a bit frustrated. Still appreciate all that goes on here. Thank all of
>you.
> Wish all good holiday type feelings.
Ok, so you have a device that needs a firmware download to be supported by
the ordinary usb storage driv
Hi,
this adds module usage count handling during probe and disconnect to the
usb core. It applies to 2.5.1 and is now in the smallest possible form.
I did not go at the old style probe, as it shoulde be IMO removed.
Greg, please apply.
Regards
Oliver
--- include/linux/
> - USB modem:
> - Simon only has 1 modem, so no matter where he plugges it in on
> the USB topology, it will always be referenced as the same
> modem: /dev/ttyACM0
But will any settings he has made to his modem be restored ?
If he presses suspend while his terminal program is
> > The first three cases must be dealt with like normal hotplugging
> > just deferred to the time we wake up.
>
> That deferring may not always be possible. As an example, take a system
> in use by a friend of mine, basically a laptop with the keyboard not
> part of the main unit, but on the end
> > - all usb-ethernet bridges (swapping over NFS)
>
> Kaweth needs load-at-init firmware, others (now in the
> Linux kernel anyway) don't.
>
> ... so I don't see _any_ special cases there
Two things.
Firstly we should not opt for a design that precludes optionally
handling such devices.
Secondly
> Suspend is quite different from power-cut as devices are still allowed to
> draw up to 0.5mA from the suspended USB (see 9.2.3, USB spec.). While
> being enough for a pm-aware microcontroler to keep its state information
> (like fn-address, device-config, interface alternate setting) in the
> m
> If we're talking USB here (and in some cases even if we're not), we need
> to deal with more than that. Specifically, we need to be able to deal
> with the following sequences:
>
> ==> Device plugged in and initialised.
> Machine suspended.
> Device unplugged.
> Machine resum
> And if your swap device is mounted over nfs through a ppp connection on
> a usb-serial device that needs firmware downloaded to it, you deserve
> any problems that this might cause :)
For a serial device you are probably right. For eg a DSL device you are
not right.
I'll join the discussion af
On Thu, 13 Dec 2001, David Brownell wrote:
> > To summarise, we can either have firmware handling in user
> > space or power management, but not both.
>
> What specific devices that have this problem?
Any storage or communication device that is buspowered and needs
a firmware download.
> They'd
On Thu, 13 Dec 2001, Martin Diehl wrote:
> On Thu, 13 Dec 2001 [EMAIL PROTECTED] wrote:
>
> > Firstly, let me clarify that the problem is with _reloading_ firmware
> > due to resumption from power management.
>
> Absolutely. But note, that is not the only problem: If the driver has to
> manage dy
> > To summarise, we can either have firmware handling in user space or power
> > management, but not both.
> > More philosophically speaking, IMHO we have a classical layering violation
> > caused by wishful thinking.
> > To quote Dave: "There are many good reasons to have device handling in
> >
Hi people,
it seems my explanation was too short.
Firstly, let me clarify that the problem is with _reloading_ firmware
due to resumption from power management.
During resumption from power save, our ability to allocate memory is
severly constrained. We may allocate memory only with GFP_NOIO or
On Mon, 3 Dec 2001, Pete Zaitcev wrote:
> > To: Greg KH <[EMAIL PROTECTED]>
> > cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
> > Date: Tue, 4 Dec 2001 01:04:35 +0100 (MET)
>
> > On Mon, 3 Dec 2001, Greg KH wrote:
> > > On Sun, Dec 02, 2001 at 12:38:08PM +0100, Oliver Neukum wrote:
> > > >
> > > >
On Mon, 3 Dec 2001, Greg KH wrote:
> On Sun, Dec 02, 2001 at 12:38:08PM +0100, Oliver Neukum wrote:
> >
> > Here I don't understand you. Certainly an URB pool could be used. But why
> > would it prevent needing to wait. IMHO it would just mean waiting for a pool
> > of URBs to finish instead of w
On Thu, 1 Nov 2001, Duncan Sands wrote:
> I see from the code that disconnect and probe calls are serialized:
> one won't be called during the other. However, what about
> usbdevfs ioctl calls? I am worried that ioctl (the one you can specify
> in the usb_driver struct) can be called during or
On Mon, 22 Oct 2001, Thomas Sailer wrote:
> Oliver Neukum schrieb:
>
> > The only problem you have then is that a generic driver would need to give up
> > its devices whenever a new driver is probed. But that problem is not harder
> > than dealing with disconnect.
>
> A generic driver also prohib
Hi list,
I have acquired an OHCI(no name, Lucent chip) on a PCI card.
The card is not detected as PCI device. I even tried 'lspci -H1 -M'.
H2 crashes the box.
This is aan old P100 with UMC chipset. I tried pci=bios,conf1 and
conf2without success..
TIA
Oliver
_
On Fri, 4 May 2001, Martin Diehl wrote:
> On Fri, 4 May 2001, Oliver Neukum wrote:
>
> > Whatever you report to user space is not relevant for the problem.
> > After an URB has completed, you need to process the buffer or you'll lose
> > data.
>
> I still don't see the problem. The driver detects
On Fri, 4 May 2001, Greg KH wrote:
> On Thu, May 03, 2001 at 09:18:05AM +0200, Oliver Neukum wrote:
> > Hi listmembers,
> >
> > there was a request to explain how to get away from sleep_on and relatives.
>
> Any hints on how to replace interruptible_sleep_on_timeout() which is
> what is used in m
36 matches
Mail list logo
