From: Dmitry Torokhov <dtor_core@ameritech.net>
To: Greg KH <greg@kroah.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Patrick Mochel <mochel@osdl.org>
Subject: Re: Driver core change request
Date: Tue, 12 Oct 2004 01:29:59 -0500 [thread overview]
Message-ID: <200410120129.59221.dtor_core@ameritech.net> (raw)
In-Reply-To: <20041008214820.GA1096@kroah.com>
On Friday 08 October 2004 04:48 pm, Greg KH wrote:
> On Thu, Oct 07, 2004 at 09:59:10PM -0500, Dmitry Torokhov wrote:
> > On Thursday 07 October 2004 04:40 pm, Greg KH wrote:
> > > On Wed, Oct 06, 2004 at 11:54:18PM -0500, Dmitry Torokhov wrote:
> > > > Hi,
> > > >
> > > > I am reworking my sysfs serio patches (trying to get dynamic psmouse
> > > > protocol switching) and I am wondering if we could export device_attach
> > > > function. Serio system allows user to request device rescan - force current
> > > > driver to let go off the device and find another suitable driver. Also user
> > > > can manually request device to be disconnected/connected to a driver. By
> > > > having device_attach exported I could get rid of some duplicated code.
> > >
> > > driver_attach() is global, so I don't have a problem with making
> > > device_attach() global either. Just send me a patch :)
> > >
> >
> > OK. BTW, while driver_attach is global it is not exported. Should I mark both
> > of them EXPORT_GPL_ONLY?
>
> No, pci can not be a module. Can your serio core be a module? If not,
> just make it global. But if so, yes, EXPORT_SYMBOL_GPL() is the proper
> marking.
>
Yes serio and gameport (which I am planning to convert to driver model as well)
can be built as modules.
> > > > I.e driver_probe_device is exported. Does it have a chance to be accepted?
> > >
> > > What's wrong with doing what the pci core does in this situation and
> > > call driver_attach()?
> > >
> >
> > Well, I need to be able to work with a specific port so when I am doing
> >
> > echo -n "serio_raw" > /sys/bus/serio/devices/serio1/driver
> >
> > I want only serio1 be affected, not every disconnected port that can work
> > with serio_raw. driver_attach() will claim all of them.
> >
> > The difference is that serio system allows you to have several drivers
> > that can drive the same hardware and user gets to chose which driver gets
> > the honors. I.e given 4 PS/2 ports in the system user might want to have
> > raw access to port #2 (via serio_raw) while using standard psmouse driver
> > for the rest of them. With PCI if you have 2 drivers and 2 exactly same
> > cards you do not have ability to bind first driver to one of the cards and
> > second driver to the other.
>
> Nice. We want to make this kind of functionality avaiable to all
> busses, and not have it be a bus only type feature. So if you can see
> any way it could be moved into the core, I'd be all for it.
>
I have been looking at it entire weekend and I do not presently see a way to
make this facility truly generic. That is because pretty much all buses
perform additional steps besides code in driver->remove() which driver core
does is not aware of. What is needed it bus->device_disconnect function that
would disconnect device and probably destroy all children.
For now I added:
- "driver" default device attribute that produces name of currently bound
driver uppon read.
- bus->rebind_handler method that is called when someone writes to "driver"
attribute and allows to perform bunctions like disconnecting device or
rebinding it to alternative driver in bus-specific way.
- "bind_mode" default device and driver attributes that can be "auto" or
"manual". When device or driver marked as manual bind device_attach()
and driver_attach() will ignore them. They are expected to be bound by
bus->rebind_handler (via driver_probe_device()).
I also renamed bus_match to driver_probe_device() and exported it, along
with device_attach and driver_attach.
Please let me know if its acceptable.
The patches are suitable for importing with bkimport utility (by Bjorn
Helgaas?) that allows preserve per-file comments.
http://www.geocities.com/dt_or/misc/
--
Dmitry
next prev parent reply other threads:[~2004-10-12 6:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-07 4:54 Driver core change request Dmitry Torokhov
2004-10-07 21:40 ` Greg KH
2004-10-08 2:59 ` Dmitry Torokhov
2004-10-08 21:48 ` Greg KH
2004-10-12 6:29 ` Dmitry Torokhov [this message]
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-12 6:32 ` [PATCH 3/4] Driver core: add "driver" default attribute Dmitry Torokhov
2004-10-12 6:33 ` [PATCH 4/4] Driver core: add "bind_mode" " Dmitry Torokhov
2004-10-29 16:37 ` [PATCH 2/4] Driver core: add driver_probe_device Greg KH
2004-10-29 18:24 ` Dmitry Torokhov
2004-10-29 18:32 ` Greg KH
2004-10-29 16:37 ` [PATCH 1/4] Driver core: export device_attach Greg KH
2004-10-21 7:05 ` Driver core change request Dmitry Torokhov
2004-10-21 14:50 ` 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=200410120129.59221.dtor_core@ameritech.net \
--to=dtor_core@ameritech.net \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.