From: Dmitry Torokhov <dtor_core@ameritech.net>
To: Greg KH <greg@kroah.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Patrick Mochel <mochel@digitalimplant.org>
Subject: Re: [PATCH 2/4] Driver core: add driver_probe_device
Date: Sat, 30 Oct 2004 03:26:22 -0500 [thread overview]
Message-ID: <200410300326.23345.dtor_core@ameritech.net> (raw)
In-Reply-To: <20041029202249.GB29171@kroah.com>
On Friday 29 October 2004 03:22 pm, Greg KH wrote:
> Ok, care to redo the "driver" patch to be a symlink instead? I think
> the last patch doesn't really need any changes, does it?
>
Coming your way.
> Hm, but how does this play with the current pci "add a new device id"
> scheme? Can this "bind_mode" scheme work with that?
>
They really serve different purposes as far as I can see. new_id affects
matching (and is PCI specific), bind_mode affects binding of otherwise
matching device/driver pairs. Its main use is to give preference to one
driver and "punish" another.
For example we have atkbd, psmouse and serio_raw drivers working with
PS/2 ports. atkbd and psmouse are integrated into input subsystem and we
want to encourage their use. Still we don't support (rather detect) all
existing hardware yet so in some case raw access to PS/2 port (a-la 2.4
and earlier kernels) is desirable, so we have serio_raw. But because we
don't want it grab all free serio ports even if it loaded first it is
marked as manual bind.
Another example - you for some reason don't like touchpads and prefer an
external mouse. BUt the way serio subsystem works, even if you disconnect
serio port next time there is data it will try to find the driver again
- so you mark your port as manual bind to prevent new input device from
appearing.
The bind_mode can also be used to control experimental/deprecated features
and still have everything compiled/loaded.
--
Dmitry
next prev parent reply other threads:[~2004-10-30 8:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-29 18:57 [PATCH 2/4] Driver core: add driver_probe_device Dmitry Torokhov
2004-10-29 20:22 ` Greg KH
2004-10-30 8:26 ` Dmitry Torokhov [this message]
2004-10-30 8:27 ` [PATCH 1/4] Driver core: add driver symlink to device Dmitry Torokhov
2004-10-30 8:28 ` [PATCH 2/4] Driver core: add drvctl device attribute Dmitry Torokhov
2004-10-30 8:28 ` [PATCH 3/4] Driver core: add bind_mode device/driver attributes Dmitry Torokhov
2004-10-30 8:29 ` [PATCH 4/4] Driver core: bus_rescan_devices improper locking Dmitry Torokhov
2004-11-01 22:43 ` [PATCH 1/4] Driver core: add driver symlink to device Greg KH
-- strict thread matches above, loose matches on Subject: below --
2004-10-07 4:54 Driver core change request Dmitry Torokhov
2004-10-12 6:29 ` Dmitry Torokhov
2004-10-12 6:31 ` [PATCH 1/4] Driver core: export device_attach Dmitry Torokhov
2004-10-12 6:31 ` [PATCH 2/4] Driver core: add driver_probe_device Dmitry Torokhov
2004-10-29 16:37 ` Greg KH
2004-10-29 18:24 ` Dmitry Torokhov
2004-10-29 18:32 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200410300326.23345.dtor_core@ameritech.net \
--to=dtor_core@ameritech.net \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox