On Wed, 6 Apr 2005, Alan Stern wrote:
> The patch looks good. But isn't there still a problem with
> device_release_driver()? It doesn't wait for the klist_node to be removed
> from the klist before unlocking the device and moving on. As a result, if
> another driver was waiting to bind to the
On Wed, 6 Apr 2005, Patrick Mochel wrote:
> > Third, why does device_release_driver() call klist_del() instead of
> > klist_remove() for dev->knode_driver? Is that just a simple mistake?
> > The klist_node doesn't seem to get unlinked anywhere.
>
> It can be called from driver_for_each_device()
Sorry about the delay in responding, there were some bugs to attend to,
some of which you may have inadvertantly caught below.
On Sat, 2 Apr 2005, Alan Stern wrote:
> I looked through the new driver model code a bit more. There appears to
> be a few problems (unless I'm using out-of-date code).
Pat:
I looked through the new driver model code a bit more. There appears to
be a few problems (unless I'm using out-of-date code).
First, there's a race between adding a new device and registering a new
driver. The bus_add_device() routine contains these lines:
pr_debug("bus %s: add
On Thu, 31 Mar 2005, Patrick Mochel wrote:
> > > > Whenever usb_register() in the USB core calls driver_register()
> > > > and the call filters down to driver_attach(), that routine
> > > > should lock dev->parent->sem before calling
> > > > driver_probe_device()
> > > >
On Thu, 31 Mar 2005, David Brownell wrote:
> On Thursday 31 March 2005 10:26 am, Patrick Mochel wrote:
> > Conversely, we only want to automatically suspend the device, or allow the
> > device to be explicitly put to sleep, if the device is not being used.
>
> And be able to suspend itself, even
On Thu, 31 Mar 2005 10:26:36 -0800 (PST), Patrick Mochel
<[EMAIL PROTECTED]> wrote:
> I don't understand what you mean. Even if a device is suspended, be it
> automatically after some amount of inactivity or as directed explicitly by
> a user, we want to be able to open the device and have it work.
On Thursday 31 March 2005 10:26 am, Patrick Mochel wrote:
>
> On Thu, 31 Mar 2005, David Brownell wrote:
>
> > On Thursday 31 March 2005 9:59 am, Patrick Mochel wrote:
> > > On Thu, 31 Mar 2005, Alan Stern wrote:
> > > > On Wed, 30 Mar 2005, Patrick Mochel wrote:
> > >
> > > > > In fact, we proba
On Thu, 31 Mar 2005, David Brownell wrote:
> On Thursday 31 March 2005 9:59 am, Patrick Mochel wrote:
> > On Thu, 31 Mar 2005, Alan Stern wrote:
> > > On Wed, 30 Mar 2005, Patrick Mochel wrote:
> >
> > > > In fact, we probably want to add a counter to every device for all "open
> > > > connection
On Thursday 31 March 2005 9:59 am, Patrick Mochel wrote:
> On Thu, 31 Mar 2005, Alan Stern wrote:
> > On Wed, 30 Mar 2005, Patrick Mochel wrote:
>
> > > In fact, we probably want to add a counter to every device for all "open
> > > connections" so the device doesn't try to automatically sleep whil
On Thu, 31 Mar 2005, Alan Stern wrote:
> On Wed, 30 Mar 2005, Patrick Mochel wrote:
>
> > > Having thought it through, I believe all we need for USB support is this:
> > >
> > > Whenever usb_register() in the USB core calls driver_register()
> > > and the call filters down to driver_attach(),
On Thu, 31 Mar 2005, Alan Stern wrote:
> On Wed, 30 Mar 2005, Patrick Mochel wrote:
> > In fact, we probably want to add a counter to every device for all "open
> > connections" so the device doesn't try to automatically sleep while a
> > device node is open. Once it reaches 0, we can have it en
On Wed, 30 Mar 2005, Patrick Mochel wrote:
> > Having thought it through, I believe all we need for USB support is this:
> >
> > Whenever usb_register() in the USB core calls driver_register()
> > and the call filters down to driver_attach(), that routine
> > should lock dev->parent->s
On Wed, 30 Mar 2005, Patrick Mochel wrote:
> Let me re-phrase that: The driver core will never explicitly take more
> than 1 lock. It will lock a device during calls to the driver routines,
> which the drivers should be aware of when re-entering the driver model via
> those functions.
Okay.
> >
On Wed, 30 Mar 2005, Dmitry Torokhov wrote:
> Will the lock be exported (via helper functions)? I always felt dirty using
> subsys.rwsem because it I think it was supposed to be implementation detail.
Sure, why not? See the attached patch for helpers, exported GPL only of
course.
Thanks,
On Wednesday 30 March 2005 21:16, Patrick Mochel wrote:
>
> On Tue, 29 Mar 2005, Alan Stern wrote:
>
> > On Mon, 28 Mar 2005, Patrick Mochel wrote:
> >
> > > How is this related to (8) above? Do you need some sort of protected,
> > > short path through the core to add the device, but not bind it
On Tue, 29 Mar 2005, Alan Stern wrote:
> On Mon, 28 Mar 2005, Patrick Mochel wrote:
>
> > How is this related to (8) above? Do you need some sort of protected,
> > short path through the core to add the device, but not bind it or add it
> > to the PM core?
>
> Having thought it through, I believe
On Mon, 28 Mar 2005, Alan Stern wrote:
> > For now, I'm willing to punt on those and consider them subsystem-specific
> > until more is known about those situations' characteristics. As it
> > currently stands, the core will not lock more than 1 device at a time.
>
> That's absolutely not true.
On Mon, 28 Mar 2005, Alan Stern wrote:
> On Mon, 28 Mar 2005, Patrick Mochel wrote:
> > Do you have suggestions about an alternative (with code)?
>
> Here's something a little better than pseudocode but not as good as a
> patch... :-)
> To fill the first field in correctly requires that klist c
On Tue, 29 Mar 2005 11:18:13 -0500 (EST), Alan Stern
<[EMAIL PROTECTED]> wrote:
>
> With that change in place we can guarantee that every time a USB driver's
> probe() is called, both the interface and the parent device are locked.
>
> I don't know how cleanly this can be implemented. You probab
On Mon, 28 Mar 2005, Patrick Mochel wrote:
> How is this related to (8) above? Do you need some sort of protected,
> short path through the core to add the device, but not bind it or add it
> to the PM core?
Having thought it through, I believe all we need for USB support is this:
Whenev
On Mon, 28 Mar 2005, Patrick Mochel wrote:
> The only race I see is the klist_remove() in bus_remove_driver() racing
> with the iteration of the klist in device_attach(). The former will block
> until the driver.knode_bus reference count reaches 0, which will happen
> when the ->probe() is over an
On Mon, 28 Mar 2005, Patrick Mochel wrote:
> It's important when removing a containing object's knode from the list
> when that object is about to be freed. This happens during both device and
> driver unregistration. In most cases, the removal operation will return
> immediately. When it doesn't,
On Mon, 28 Mar 2005, David Brownell wrote:
> On Monday 28 March 2005 9:44 am, Patrick Mochel wrote:
>
> > How is this related to (8) above? Do you need some sort of protected,
> > short path through the core to add the device, but not bind it or add it
> > to the PM core?
>
> Erm, why is there a
On Monday 28 March 2005 9:44 am, Patrick Mochel wrote:
> How is this related to (8) above? Do you need some sort of protected,
> short path through the core to add the device, but not bind it or add it
> to the PM core?
Erm, why is there a distinction between "adding device" and "adding it
to the
On Sat, 26 Mar 2005, Alan Stern wrote:
> Let's move on to consider the new struct device.sem. You've
> recognized, like other people, that such a thing is necessary to
> protect drivers against simultaneous callbacks. But things aren't as
> simple as just sticking the semaphore into the structu
On Sat, 26 Mar 2005, Alan Stern wrote:
> Pat:
>
> Your recent series of driver model patches naturally divides up into
> two parts: those involved with implementing and using klists, and
> those involved with adding a semaphore to struct device. Let's
> consider these parts separately.
I've spl
Pat:
Your recent series of driver model patches naturally divides up into
two parts: those involved with implementing and using klists, and
those involved with adding a semaphore to struct device. Let's
consider these parts separately.
The klist stuff embodies a good idea: safe traversal of list
28 matches
Mail list logo
