lkml.org 
[lkml]   [2004]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] PNP support for i8042 driver
Date
On Tuesday 16 November 2004 12:37 am, Adam Belay wrote:
> 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.
>

Adam,

I agree with your point that every device in the system should have a
driver attached. And i8042 does have one bound to it. It is i8042 platform
driver that does power management and ensures proper integration into driver
model.

There is no need to keep secondary "drivers" around, their sole purpose is
to provide information about avalilable resources. It would be ok if the
code was shared among several devices on a bus but for most (all?) legacy
devices it has to be programmed explicitely and will not be reused.

Also i8042 should not rely on either ACPI or PNP simply because the driver/
chip works on boxes other than x86/ia64 so we can't make ACPI or PNP drivers
"main" ones.

As far as binding/rebinding goes I guess sysdevs and platform devices will
just disable this functionality.

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

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.123 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site