Re: [PATCH 2/4] Driver core: add driver_probe_device

From: Greg KH
Date: Fri Oct 29 2004 - 13:53:31 EST


On Fri, Oct 29, 2004 at 01:24:21PM -0500, Dmitry Torokhov wrote:
> On Friday 29 October 2004 11:37 am, Greg KH wrote:
> > On Tue, Oct 12, 2004 at 01:31:36AM -0500, Dmitry Torokhov wrote:
> > > #### AUTHOR dtor_core@xxxxxxxxxxxxx
> > > #### COMMENT START
> > > ### Comments for ChangeSet
> > > Driver core: rename bus_match into driver_probe_device and export
> > > it so subsystems can bind an individual device to a
> > > specific driver without getting involved with driver
> > > core internals.
> >
> > Applied, thanks.
> >
>
> Greg,
>
> What about "bind_mode" device and driver attributes? If you are not going
> to apply them then I need to rework driver_probe_device to not call
> bus->match() function.

Hm, I'm not going to apply them, but haven't written that email yet,
sorry.

Is things now broken with only these 2 patches applied?

> The reason is that if bind_mode is not in the core
> then I need to check these attributes in serio's bus match function, but
> then I will not be able to use driver_probe_device to force binding when
> user requests it. And if I don't check bind_mode in serio_bus_match then
> I will have to do all driver/device mathing by hand which I wanted to
> avoid in the first place.

Heh, I understand. I like the ideas of your next patches, but just not
the implementation.

I really like the "driver" part in the device. But not as a file, let's
make it a symlink back to the driver that is bound to the device at that
point in time. This makes it just like the other symlinks in the sysfs
tree.

But if we do that, we still don't have a way to implement what you are
really trying to do (and it breaks your code as you already have a
driver file.) I'll work on what I propose instead in my next message
(will be a few hours, have real work to do for a bit, sorry...)

thanks,

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