lkml.org 
[lkml]   [2004]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 2.6.10-rc1 4/4] driver-model: attach/detach sysfs node implemented
Date
On Thursday 04 November 2004 11:45 pm, Tejun Heo wrote:
> Hello Dmitry. Hello Greg.
>
> On Thu, Nov 04, 2004 at 11:06:19AM -0800, Dmitry Torokhov wrote:
> > What about connecting? I am pretty ignorant of USB inner workings
> > but when I took a glance there seems to be a lot of preparations
> > before device is ready to be probed...
>
> IMHO, it would be better to coerce whatever bus to follow common
> driver-model synchronization/attach/detach rules and be able to do
> straight-forward implementation of features in the core driver-model.
> If the current driver-model isn't enough, the core code should be
> expanded rather than doing bus-specific dances in individual buses.
> But I don't really know about any bus other than PCI, so maybe I'm
> being too naive.
>

The main problem I guess is that driver model does not allow registering
or removal of child devices during driver->probe() on the same bus. So
every bus does it its own way. Plus most buses were around way before
driver model so their historical locking rules affect this as well.
Down the road, as the stuff gets cleaned we can have a shot of pulling
bus code into drivre core, but not yet I think.

> > > problems (as long as it's not the hub driver from a hub device, we need
> > > to never be able to disconnect those.)
> >
> > Never say never ;) That was the first thing I did after playing with
> > PCI devices when I tried doing what Tejun did.
> >
> > If kernel advertises an userspace interface it will be used. I can see
> > myself wanting to disconnect my hub and all its devices so my wireless
> > explorer does not use batteries and I do not want to figure out what
> > port it is connected to... Someone else will find another reason,
> > I don't know.
> >
> > I also think that even PCI should kill children devices behind a bridge
> > if bridge driver is disconnected to manage resources in more strict way.
> > But I think that would require notion of generic/specialized driver and
> > require automatic rebinding of specialized driver over generic one so
> > every PCI device has a driver attached to it.
>
> I think above can be cleanly solved by enforcing that no device can
> be attached to a driver unless all its ancestors are attached to a
> driver. The check can be made easiliy inside the driver-model, and,
> if needed, making dummy drivers for internal node devices which
> orignally didn't need one shouldn't be difficult.

Right now not all parent PCI devices have drivers. IIRC there were talks
about implementing generic bridge driver but then some bridges need special
handling and the concern was that generic driver would prevent binding of
a special driver.

> We can just return
> -EBUSY for any attempts to detach an internal device which has
> driver-attached children. This way, recursing and all other chores
> can be dumped to user-space where they belong.
>

The system needs to handle situation when you physically yanking part of a
device tree and get rid of all devices, like in cases when you pull an USB
cable connected to a HUB with a mouse and a scanner and a pinter and whatever
else out there. We need to get rid of all these devices and I am not sure
that offloading this task to userspace is good idea. Especially if removal
happens when the box is suspended and at wakeup we have completely different
set of devices...

> And regarding the duplicate works, my work on manual-attach was
> primarily to show how dynamic device-driver binding can work with
> devparam; also, Dmitry seems to understand the problem better than me.
> So, I think I should back off on manualattach. Dmitry, what do you
> think about integrating devparam with your work?
>

I do not see why we shoudln't but first I need to persuade Greg to apply
my patches ;)

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.039 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site