From: ambx1@neo.rr.com (Adam Belay)
To: Dmitry Torokhov <dtor_core@ameritech.net>
Cc: linux-kernel@vger.kernel.org,
matthieu castet <castet.matthieu@free.fr>,
bjorn.helgaas@hp.com, vojtech@suse.cz, "Brown,
Len" <len.brown@intel.com>,
greg@kroah.com
Subject: Re: [PATCH] PNP support for i8042 driver
Date: Tue, 16 Nov 2004 00:37:41 -0500 [thread overview]
Message-ID: <20041116053741.GD29574@neo.rr.com> (raw)
In-Reply-To: <200411140148.02811.dtor_core@ameritech.net>
On Sun, Nov 14, 2004 at 01:48:00AM -0500, Dmitry Torokhov wrote:
> On Saturday 13 November 2004 08:23 am, matthieu castet wrote:
> > Hi,
> > this patch add PNP support for the i8042 driver in 2.6.10-rc1-mm5. Acpi
> > is try before the pnp driver so if you don't disable ACPI or apply
> > others pnpacpi patches, it won't change anything.
> >
> > Please review it and apply if possible
> >
> > thanks,
> >
> > Matthieu CASTET
> >
> > Signed-Off-By: Matthieu Castet <castet.matthieu@free.fr>
> >
>
> Hi,
>
> Do we really need to keep those drivers loaded - i8042 will not
> be hotplugged and ports are reserved anyway. We are only interested
> in presence of the keyboard and mouse ports. Can we unregister
> the drivers (both ACPI and PNP) right after registering and mark
> all that stuff as __init/__initdata as in the patch below?
> I also adjusted init logic so ACPI/PNP can be enabled/disabled
> independently of each other.
>
> --
> Dmitry
As a general convention, I think we do. This should apply to every bus and
driver. Every hardware component should have a driver bound to it.
Otherwise, we can't take full advantage of sysfs. We really need a driver to
link the physical device to logical "class" abstractions . Futhermore, as we
extend the functionality of the driver core (ex. manual binding and unbinding)
_init will cause many headaches. Also, unloading the driver is not good for
power management. This case may not apply to every device, but in most cases
we need to have a driver loaded before suspending a piece of hardware, as only
that driver can be sure of how to handle the device correctly.
It may not always be the most efficient solution for legacy hardware, but, at
least, if we require legacy drivers to behave like any other driver, then we
can ensure a minimum level of functionalily and flexability. This set of
standards will help ensure that legacy hardware can coexist nicely with more
modern solutions. That's really one of the main advantages of a layered
design like the driver model.
Thanks,
Adam
next prev parent reply other threads:[~2004-11-16 5:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-13 13:23 [PATCH] PNP support for i8042 driver matthieu castet
2004-11-14 6:48 ` Dmitry Torokhov
2004-11-14 12:22 ` matthieu castet
2004-11-15 14:41 ` Dmitry Torokhov
2004-11-15 19:51 ` matthieu castet
2004-11-15 20:28 ` Dmitry Torokhov
2004-11-15 22:52 ` matthieu castet
2004-11-15 23:09 ` matthieu castet
2004-11-16 5:52 ` Adam Belay
2004-11-16 6:27 ` Dmitry Torokhov
2004-11-16 5:37 ` Adam Belay [this message]
2004-11-16 5:44 ` Greg KH
2004-11-16 6:06 ` Dmitry Torokhov
2004-11-16 6:24 ` Adam Belay
2004-11-17 10:07 ` Vojtech Pavlik
2005-02-04 17:37 ` matthieu castet
2005-02-04 18:28 ` Vojtech Pavlik
2005-02-04 22:54 ` matthieu castet
2005-02-05 13:48 ` matthieu castet
2005-02-05 18:51 ` Dmitry Torokhov
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=20041116053741.GD29574@neo.rr.com \
--to=ambx1@neo.rr.com \
--cc=bjorn.helgaas@hp.com \
--cc=castet.matthieu@free.fr \
--cc=dtor_core@ameritech.net \
--cc=greg@kroah.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vojtech@suse.cz \
/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