From: Dmitry Torokhov <dtor_core@ameritech.net>
To: Adam Belay <abelay@novell.com>
Cc: greg@kroah.com, rml@novell.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] add driver matching priorities
Date: Fri, 28 Jan 2005 18:51:28 -0500 [thread overview]
Message-ID: <200501281851.28475.dtor_core@ameritech.net> (raw)
In-Reply-To: <1106955187.29709.24.camel@localhost.localdomain>
On Friday 28 January 2005 18:33, Adam Belay wrote:
> On Fri, 2005-01-28 at 18:23 -0500, Dmitry Torokhov wrote:
> > On Friday 28 January 2005 17:30, Adam Belay wrote:
> > > Of course this patch is not going to be effective alone. We also need
> > > to change the init order. If a driver is registered early but isn't the
> > > best available, it will be bound to the device prematurely. This would
> > > be a problem for carbus (yenta) bridges.
> > >
> > > I think we may have to load all in kernel drivers first, and then begin
> > > matching them to hardware. Do you agree? If so, I'd be happy to make a
> > > patch for that too.
> > >
> >
> > I disagree. The driver core should automatically unbind generic driver
> > from a device when native driver gets loaded. I think the only change is
> > that we can no longer skip devices that are bound to a driver and match
> > them all over again when a new driver is loaded.
> >
>
> That's another option. My concern is that if a generic driver pokes
> around with hardware, it may fail to initialize properly when the actual
> driver is loaded. There are other problems too. If the system were to
> be suspended while the generic driver was loaded, the restore_state code
> may be incorrect, also rendering the device unusable.
>
If generic driver binds to a device that is has no idea how to drive
_at all_ then I will argue that the generic driver is broken. It should
not bind to begin with.
--
Dmitry
next prev parent reply other threads:[~2005-01-28 23:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-28 22:30 [RFC][PATCH] add driver matching priorities Adam Belay
2005-01-28 23:23 ` Dmitry Torokhov
2005-01-28 23:33 ` Adam Belay
2005-01-28 23:51 ` Dmitry Torokhov [this message]
2005-01-29 0:05 ` Adam Belay
2005-01-29 0:11 ` Al Viro
2005-01-29 2:45 ` Dmitry Torokhov
2005-02-10 8:41 ` Greg KH
2005-02-10 17:18 ` Adam Belay
2005-02-10 18:08 ` Dmitry Torokhov
2005-02-10 18:12 ` Greg KH
2005-02-10 21:26 ` Adam Belay
2005-02-10 18:33 ` Greg KH
2005-02-10 18:46 ` Dmitry Torokhov
2005-02-10 21:32 ` Adam Belay
2005-02-10 18:45 ` Russell King
2005-02-10 21:37 ` Adam Belay
2005-02-25 23:41 ` Greg KH
2005-03-01 0:05 ` Adam Belay
2005-03-01 7:58 ` 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=200501281851.28475.dtor_core@ameritech.net \
--to=dtor_core@ameritech.net \
--cc=abelay@novell.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@novell.com \
/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.