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 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, but it's not relevant to the __MOD_* change
that I
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
> > 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 Fri, Dec 21, 2001 at 10:41:43AM -0800, David Brownell wrote:
> > > > I did not go at the old style probe, as it shoulde be IMO removed.
> > >
> > > 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
> > 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.
And you're expecting every probe() to not sleep
> > > I did not go at the old style probe, as it shoulde be IMO removed.
> >
> > 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 o
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
11 matches
Mail list logo
