about probing a device

[wit]

Hi,
I found these routines in the kernel, does this means only one driver
can be matched to a device? What if two drivers both can drive the
device, like sd & sg in scsi subsystem?

static int device_attach(struct device * dev)
{
struct bus_type * bus = dev->bus;
struct list_head * entry;
int error;

if (dev->driver) {
device_bind_driver(dev);
return 1;
}

if (bus->match) {
list_for_each(entry, &bus->drivers.list) {
struct device_driver * drv = to_drv(entry);
error = bus_match(dev, drv);
if (!error)
/* success, driver matched */
return 1;
if (error != -ENODEV && error != -ENXIO)
/* driver matched but the probe failed */
printk(KERN_WARNING
"%s: probe of %s failed with error %d\n",
drv->name, dev->bus_id, error);
}
}

return 0;
}

void driver_attach(struct device_driver * drv)
{
struct bus_type * bus = drv->bus;
struct list_head * entry;
int error;

if (!bus->match)
return;

list_for_each(entry, &bus->devices.list) {
struct device * dev = container_of(entry, struct device, bus_list);
if (!dev->driver) {
error = bus_match(dev, drv);
if (error && (error != -ENODEV))
/* driver matched but the probe failed */
printk(KERN_WARNING
"%s: probe of %s failed with error %d\n",
drv->name, dev->bus_id, error);
}
}
}

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

[Greg KH]

Post by wit
Hi,
I found these routines in the kernel, does this means only one driver
can be matched to a device?

Yes, you are correct, that is how the driver model currently works.

Post by wit
What if two drivers both can drive the device, like sd & sg in scsi
subsystem?

You have to go through a lot of pain to get it to work :)

Or create a virtual bus and devices, but that is not how scsi decided to
go about this.

I do have some half-baked patches to fix this in a generic way, to allow
multiple drivers to bind to devices, but it's not fully working right
now and I got side-tracked by having to clean up the kset/kobject/ktype
mess first to get this to work properly, so it might be a few months.

Why, is there some use for multiple drivers to devices that you want to
use?

thanks,

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

[Greg KH]

Post by wit
Thanks very much

Post by Greg KH
Why, is there some use for multiple drivers to devices that you want to
use?

I'm just trying to figure out the difference between 2.4 & 2.6 device
drivers. And this is just an issue that came up to my mind suddently.

For 2.4, we could not bind multiple drivers to devices either, so this
should not have changed.

thanks,

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

[Alan Cox]

On Wed, 10 Oct 2007 09:39:44 +0800

Post by wit
Hi,
I found these routines in the kernel, does this means only one driver
can be matched to a device? What if two drivers both can drive the
device, like sd & sg in scsi subsystem?

The first one which matches and successfully attaches "wins". Thus you
can allow two drivers to match an identifier and load either one or the
other. You can also deal with cases where the same identifier is used for
two different devices (eg with the revision id distinguishing them), by
having the probe methods fail if the revision is wrong.

For things like sd/sg this isn't an issue. The hardware driver interfaces
to the scsi layer which itself provides interfaces for sd, sr, sg, ... etc

If you have a PCI device with multiple device functions on one PCI
function it can be a problem. We have some special case drivers for
serial/parallel multiport cards for exactly this reason, and some ugly
hacks in AGP and EDAC that arise from this limit.

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

[wit]

Thanks very much.

Post by Alan Cox
The first one which matches and successfully attaches "wins".

Seems that calling the bind routine can bind a driver to a device. Is
there any bad side effect of doing such thing?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Cornelia Huck]

On Wed, 10 Oct 2007 23:50:01 +0800,

Post by wit

Post by Alan Cox
The first one which matches and successfully attaches "wins".

Seems that calling the bind routine can bind a driver to a device. Is
there any bad side effect of doing such thing?

If the device is already bound to another driver, it will fail.

If you have multiple drivers for the same device, just use the drivers'
bind/unbind attributes if the wrong one "won".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[wit]

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