lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200702152112.08970.david-b@pacbell.net>
Date:	Thu, 15 Feb 2007 21:12:08 -0800
From:	David Brownell <david-b@...bell.net>
To:	Len Brown <lenb@...nel.org>
Cc:	Bjorn Helgaas <bjorn.helgaas@...com>,
	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: loosen dependancy on rtc cmos

On Thursday 15 February 2007 8:38 pm, Len Brown wrote:

> So I've taken Andi's advice and checked in the patches below.

OK; that simplifies things for me, good!  I can discard that patch
(broken by Andi's pcspkr change anyway), stop worring about whether
most folk will even see that driver, and make time to look at the
ACPI hooks for RTC wakeup, instead.  :)


But it would be nice to see the PNP bus infrastructure upgraded in
various ways too, now that its availability is less iffy.

 - Add something analagous to platform_driver_probe() so that the
   init code can be removed after it runs.

 - Add shutdown() calls to the PNP bus.  Otherwise e.g. one must
   use shutdown notifiers for PNP interfaces, while normal driver
   model code works for other interfaces to such hardware.

Transitioning from "legacy" drivers to PNP (for PCs) and platform_bus
(other platforms) is a bit awkward because of differences like those.
Drivers still need too many different modes; it's too complicated to
have a core with different bus glues as thin veneers ... the glue must
be thicker (and thus error prone).  Similarly, I/O space resource
reservation acts differently.

I can hope that having PNPACPI be more common will start nudging
more drivers to get rid of their "legacy" modes, or at least focus
on "Real Driver" modes that don't involve poking at hardware and
hoping it doesn't bite back.  ;)

- Dave



> commit 243b66e76ab722cdec1921d7f80c0cb808131c37
> Author: Len Brown <len.brown@...el.com>
> Date:   Thu Feb 15 22:34:36 2007 -0500
> 
>     ACPI: always enable CONFIG_PNPACPI on CONFIG_ACPI kernels
>     
>     We removed the ACPI motherboard driver which handled
>     the ACPI=y, PNP=n case, so now we need to enforce that
>     PNP & PNPACPI are always enabled for ACPI kernels.
>     
>     Most major distros ship this way this already.
>     
>     Cc: Bjorn Helgaas <bjorn.helgaas@...com>
>     Signed-off-by: Len Brown <len.brown@...el.com>
> 


> commit 8d4956c201c2f7683289f70095443c59a39f94ef
> Author: Len Brown <len.brown@...el.com>
> Date:   Thu Feb 15 22:46:42 2007 -0500
> 
>     ACPI: remove non-PNPACPI version of get_rtc_dev()
>     
>     It isn't needed in ACPI code anymore because
>     now ACPI always includes PNPACPI.
>     
>     Cc: David Brownell <david-b@...bell.net>
>     Signed-off-by: Len Brown <len.brown@...el.com>
> 

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ