linux.kernel - 25 new messages in 22 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* UIO: Review of drivers/uio/Kconfig - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7d04fc5307434258?hl=en
* [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev. 7) -
2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/2164e63bc6a3877c?hl=en
* x86: do not reserve brk for DMI if it's not going to be used - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/addf815261c6c6ba?hl=en
* x86-32: Make AT_VECTOR_SIZE_ARCH=2 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7af8328f67e3edc6?hl=en
* adds include/asm-generic/pci-dma-common.h - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/90e1e10ba4c343d9?hl=en
* radix: move radix init early - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a6a29cc058de25ea?hl=en
* thinkpad-acpi: setup hotkey polling after changing hotkey_driver_mask - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/e850366fe374d9fc?hl=en
* CRYPTO: Fix checkpatch errors in ablkcipher.c - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d78da3b7704a409b?hl=en
* tracking memory usage/leak in "inactive" field in /proc/meminfo? - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/59f0d2bf0a30f6a8?hl=en
* SCRIPTS: Fix whitespace in get_maintainer output - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/ed7f3f69d65acf5a?hl=en
* lockdep warning for iscsi in 2.6.33-rc6 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6acaccd7f9b9f9a4?hl=en
* SCRIPTS: Better error message for checkpath.pl - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/164af3ffe0c82377?hl=en
* SCRIPTS: s/should/must/ for all ERRORs - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f25e5d83a15dab65?hl=en
* SCRIPTS: Replace four whitespaces with tabs for indentation - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/9c336ff985623486?hl=en
* CRYPTO: Fix checkpatch errors in aead.c - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2eccaf08926165bc?hl=en
* CRYPTO: Fix checkpatch errors & warnings for blowfish - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e7305b855c92e4c6?hl=en
* 2.6.33-rc6 crashes on resume - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6dc9f99de8146cff?hl=en
* CRYPTO: Fix checkpatch errors & warnings in anubis.c - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/76973ce9ae9217cc?hl=en
* CRYPTO: Fix checkpatch errors & warnings in algapi.c - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/cd00626335a77b40?hl=en
* CRYPTO: Fix checkpatch errors & warnings in api.c - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/50ecd3b3c9f0a5b2?hl=en
* sysfs: differentiate between locking links and non-links - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/dc53e1c9066cca04?hl=en
* You've been awarded - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ad2220e9a7194477?hl=en

==============================================================================
TOPIC: UIO: Review of drivers/uio/Kconfig
http://groups.google.com/group/linux.kernel/t/7d04fc5307434258?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 3:30 pm
From: "Hans J. Koch"

Two trivial fixes for the Userspace IO Kconfig file:
1) uio_sercos3 is a PCI driver, so let it depend on PCI.
2) "default n" under UIO_PCI_GENERIC is luxury since it is already the default.

Signed-off-by: Hans J. Koch <hjk@linutronix.de>
---
drivers/uio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.33-rc/drivers/uio/Kconfig
===================================================================
--- linux-2.6.33-rc.orig/drivers/uio/Kconfig 2010-02-10 00:07:18.000000000 +0100
+++ linux-2.6.33-rc/drivers/uio/Kconfig 2010-02-10 00:08:10.000000000 +0100
@@ -74,6 +74,7 @@

config UIO_SERCOS3
tristate "Automata Sercos III PCI card driver"
+ depends on PCI
help
Userspace I/O interface for the Sercos III PCI card from
Automata GmbH. The userspace part of this driver will be
@@ -87,7 +88,6 @@
config UIO_PCI_GENERIC
tristate "Generic driver for PCI 2.3 and PCI Express cards"
depends on PCI
- default n
help
Generic driver that you can bind, dynamically, to any
PCI 2.3 compliant and PCI Express card. It is useful,
--
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/

==============================================================================
TOPIC: [PATCH 8/9] PCI / ACPI / PM: Platform support for PCI PME wake-up (rev.
7)
http://groups.google.com/group/linux.kernel/t/2164e63bc6a3877c?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 9 2010 3:40 pm
From: Gary Hade

On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
> On Tue, Feb 09, 2010 at 09:19:51PM +0100, Rafael J. Wysocki wrote:
> > On Tuesday 09 February 2010, Gary Hade wrote:
> > > On Tue, Feb 09, 2010 at 08:41:16AM -0800, Gary Hade wrote:
> > > > On Tue, Feb 09, 2010 at 01:48:20PM +0100, Rafael J. Wysocki wrote:
> > > > > On Tuesday 09 February 2010, Gary Hade wrote:
> > > > > > On Mon, Feb 08, 2010 at 03:37:08PM -0800, Gary Hade wrote:
> > > > > > > On Mon, Feb 08, 2010 at 10:30:30PM +0100, Rafael J. Wysocki wrote:
> > > > > > > > On Monday 08 February 2010, Rafael J. Wysocki wrote:
> > > > > > > > > On Monday 08 February 2010, Gary Hade wrote:
> > > > > > > > > > On Sat, Feb 06, 2010 at 09:11:56PM +0100, Rafael J. Wysocki wrote:
> > > > > > > > > > > On Saturday 06 February 2010, Bjorn Helgaas wrote:
> > > > > > > > > > > > On Sunday 10 January 2010 07:01:03 am Rafael J. Wysocki wrote:
> > > > > > > > > > > > > From: Rafael J. Wysocki <rjw@sisk.pl>
> > > > > > > > > > > > >
> > > > > > > > > > > > > Although the majority of PCI devices can generate PMEs that in
> > > > > > > > > > > > > principle may be used to wake up devices suspended at run time,
> > > > > > > > > > > > > platform support is generally necessary to convert PMEs into wake-up
> > > > > > > > > > > > > events that can be delivered to the kernel. If ACPI is used for this
> > > > > > > > > > > > > purpose, a PME generated by a PCI device will trigger the ACPI GPE
> > > > > > > > > > > > > associated with the device to generate an ACPI wake-up event that we
> > > > > > > > > > > > > can set up a handler for, provided that everything is configured
> > > > > > > > > > > > > correctly.
> > > > > > > > > > > >
> > > > > > > > > > > > I think acpiphp needs a little attention after this patch. Gary
> > > > > > > > > > > > Hade noticed while testing Jesse's linux-next branch that acpiphp
> > > > > > > > > > > > complains like this:
> > > > > > > > > > > >
> > > > > > > > > > > > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > > > > > > > > acpiphp: Slot [9] registered
> > > > > > > > > > > > acpiphp: Slot [10] registered
> > > > > > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > > > > > > acpiphp: Slot [6] registered
> > > > > > > > > > > > acpiphp_glue: failed to register interrupt notify handler
> > > > > > > > > > > >
> > > > > > > > > > > > I reproduced this on an HP rx3600 (ia64), and found that acpiphp
> > > > > > > > > > > > doesn't complain on commit 82533a617f453, but it *does* complain
> > > > > > > > > > > > on commit fb3383bb4ac6e, which seems to be this patch.
> > > > > > > > > > >
> > > > > > > > > > > I can't see the possible reason looking at the code alone.
> > > > > > > > > > >
> > > > > > > > > > > Could you add a debug printk() printing the error code returned by
> > > > > > > > > > > pci_acpi_add_hp_notifier() in acpiphp_glue.c:register_slot(), please?
> > > > > > > > > >
> > > > > > > > > > Rafael, On the system where I ran into the problem it returns
> > > > > > > > > > AE_NOT_FOUND. See below.
> > > > > > > > >
> > > > > > > > > Thanks!
> > > > > > > > >
> > > > > > > > > Well, that means there's no struct acpi_device object associated with handle.
> > > > > > > > >
> > > > > > > > > I must admit I didn't take that into consideration, but it should be easily
> > > > > > > > > fixable. I'll send a patch for that later today.
> > > > > > > >
> > > > > > > > Patch appended.
> > > > > > > >
> > > > > > > > If the theory is correct, it should fix the issue. Please test.
> > > > > > >
> > > > > > > Well, acpiphp now loads OK with no disturbing messages:
> > > > > > > [ 247.360878] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> > > > > > > [ 247.385048] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> > > > > > > [ 247.385459] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > > > > > [ 247.385486] acpiphp_glue: found ACPI PCI Hotplug slot 1 at PCI 0000:02:01
> > > > > > > [ 247.385519] acpiphp: Slot [1] registered
> > > > > > > [ 247.386167] acpiphp_glue: found PCI host-bus bridge with hot-pluggable slots
> > > > > > > [ 247.386196] acpiphp_glue: found ACPI PCI Hotplug slot 2 at PCI 0000:06:01
> > > > > > > [ 247.386225] acpiphp: Slot [2] registered
> > > > > > > [ 247.386828] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0a:00.0
> > > > > > > [ 247.386861] acpiphp_glue: found ACPI PCI Hotplug slot 3 at PCI 0000:0b:00
> > > > > > > [ 247.386902] acpiphp: Slot [3] registered
> > > > > > > [ 247.387564] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:0f:00.0
> > > > > > > [ 247.387597] acpiphp_glue: found ACPI PCI Hotplug slot 4 at PCI 0000:10:00
> > > > > > > [ 247.387620] acpiphp: Slot [4] registered
> > > > > > > [ 247.388293] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:14:00.0
> > > > > > > [ 247.388324] acpiphp_glue: found ACPI PCI Hotplug slot 5 at PCI 0000:15:00
> > > > > > > [ 247.388347] acpiphp: Slot [5] registered
> > > > > > > [ 247.389041] acpiphp_glue: found PCI-to-PCI bridge at PCI 0000:19:00.0
> > > > > > > [ 247.389077] acpiphp_glue: found ACPI PCI Hotplug slot 6 at PCI 0000:1a:00
> > > > > > > [ 247.389114] acpiphp: Slot [6] registered
> > > > > > > [ 247.389736] acpiphp_glue: Bus 0000:1a has 1 slot
> > > > > > > [ 247.389739] acpiphp_glue: Bus 0000:15 has 1 slot
> > > > > > > [ 247.389742] acpiphp_glue: Bus 0000:10 has 1 slot
> > > > > > > [ 247.389746] acpiphp_glue: Bus 0000:0b has 1 slot
> > > > > > > [ 247.389748] acpiphp_glue: Bus 0000:06 has 1 slot
> > > > > > > [ 247.389751] acpiphp_glue: Bus 0000:02 has 1 slot
> > > > > > > [ 247.389753] acpiphp_glue: Total 6 slots
> > > > > > >
> > > > > > > However, I didn't have a chance to confirm that hot-add of a
> > > > > > > PCI card works correctly before someone else swiped the system
> > > > > > > from me for a while. I will verify this when I get it back,
> > > > > > > hopefully later today.
> > > > > >
> > > > > > I got the system back but unfortunately have some bad news.
> > > > > > The system has 2 hotpluggable PCI-X slots and 4 hotpluggable
> > > > > > PCIe slots. I tried hot-adding both a PCI-X card and a PCIe
> > > > > > card but acpiphp did not seem to see the hot-add event for
> > > > > > either card. acpiphp was loaded with debug=1 and issued no
> > > > > > messages when I added the cards.
> > > > >
> > > > > I gather it works without the $subject patch?
> > > >
> > > > I don't know for sure. Late Friday after running into the handler
> > > > registration issue I reverted 8/9 which required hand fixup for
> > > > one hunk failure. I then got some compile errors which I assumed
> > > > may be related to my non-removal of some of the other patches in the
> > > > series. I started reverting the entire series but got a failure right
> > > > away with 9/9 but didn't take the time to try to resolve it.
> > > >
> > > > Since it sounds like you are doubtful that your changes are
> > > > responsible for this new issue I will try to make time to fuss
> > > > with this more today.
> > >
> > > Rafael, I think I can approach this from a different direction.
> > > Except for a trivial failure with 9/9, the entire series applies
> > > to 2.6.33-rc7. I will try hot-add with 2.6.33-rc7 with and without
> > > your patches and let you know what happens.
> >
> > Yes, please, but you may want to test the appended patch first.
> >
> > If I think correctly what the problem is, it should work.
>
> OK. I already confirmed that the problem reproduces with your
> patches applied. I am now in the process of trying vanilla
> 2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give
> your patch a try.

The hot-add worked fine with an unpatched 2.6.33-rc7.

The new patch when added to the 2.6.33-rc7 tree that
included the original patchset unfortunately did not
correct the problem.

Hot-remove also seems to be acting a little strange.
After I echoed 0 to the power file for a card that was
present during boot, a read of the power file correctly
showed 0, dmesg output showed the normal remove related
messages, the green LED next to the slot transitioned
from 'on' to 'off' as it normally does, and the amber LED
next to the slot transitioned from 'off' to
'blinking on and off' as it normally does. Everything up
to this point appeared normal but after I removed the card
and closed the latch the amber LED continued
'blinking on and off' which is _not_ normal. It normally
transitions to totally 'off' after latch is closed following
removal of the card.

Gary

--
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503 IBM T/L: 775-4503
garyhade@us.ibm.com
http://www.ibm.com/linux/ltc

--
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/

== 2 of 2 ==
Date: Tues, Feb 9 2010 5:10 pm
From: "Rafael J. Wysocki"

On Wednesday 10 February 2010, Gary Hade wrote:
> On Tue, Feb 09, 2010 at 12:58:39PM -0800, Gary Hade wrote:
...
> > OK. I already confirmed that the problem reproduces with your
> > patches applied. I am now in the process of trying vanilla
> > 2.6.33-rc7. If hot-add works with 2.6.33-rc7 I will give
> > your patch a try.
>
> The hot-add worked fine with an unpatched 2.6.33-rc7.

Good.

> The new patch when added to the 2.6.33-rc7 tree that
> included the original patchset unfortunately did not
> correct the problem.

Bad.

Well, fortunately I have another one, but I haven't tested it myself yet except
for checking that it builds. Hopefully it won't break things more.

The patch below applies on top of 2.6.33-rc7 with my PCI runtime PM patchset
applied. Please test it and let me know the results.

Rafael

---
drivers/pci/pci-acpi.c | 240 ++++++++++++++++++++++++------------------------
include/acpi/acpi_bus.h | 1
2 files changed, 124 insertions(+), 117 deletions(-)

Index: linux-2.6/drivers/pci/pci-acpi.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-acpi.c
+++ linux-2.6/drivers/pci/pci-acpi.c
@@ -19,10 +19,13 @@
#include <linux/pm_runtime.h>
#include "pci.h"

-static DEFINE_MUTEX(pci_acpi_notifier_mtx);
+static DEFINE_MUTEX(pci_acpi_notify_mtx);
+static LIST_HEAD(pci_acpi_notify_list);

-struct pci_acpi_notify_data
+struct pci_acpi_notify_object
{
+ struct list_head entry;
+ acpi_handle handle;
acpi_notify_handler hp_cb;
void *hp_data;
struct pci_bus *pci_bus;
@@ -33,7 +36,7 @@ struct pci_acpi_notify_data
* pci_acpi_event_fn - Universal system notification handler.
* @handle: ACPI handle of a device the notification is for.
* @event: Type of the signaled event.
- * @ign: The value of this argument is ignored.
+ * @context: Pointer to the notify object associated with the handle.
*
* Use @handle to obtain the address of the ACPI device object the event is
* signaled for. If this is a wake-up event, execute the appropriate PME
@@ -41,116 +44,98 @@ struct pci_acpi_notify_data
* bridge). If this is not a wake-up event, execute the hotplug notify handler
* for @handle.
*/
-static void pci_acpi_event_fn(acpi_handle handle, u32 event, void *ign)
+static void pci_acpi_event_fn(acpi_handle handle, u32 event, void *context)
{
- struct acpi_device *dev;
- struct pci_acpi_notify_data *nd;
+ struct pci_acpi_notify_object *notify_obj = context;

- if (ACPI_FAILURE(acpi_bus_get_device(handle, &dev))) {
- pr_warning("ACPI handle has no context in %s!\n", __func__);
+ if (!notify_obj)
return;
- }
-
- mutex_lock(&pci_acpi_notifier_mtx);

- nd = dev->bus_data;
- if (!nd)
- goto out;
+ mutex_lock(&pci_acpi_notify_mtx);

if (event == ACPI_NOTIFY_DEVICE_WAKE) {
- if (nd->pci_bus) {
- pci_pme_wakeup_bus(nd->pci_bus);
+ if (notify_obj->pci_bus) {
+ pci_pme_wakeup_bus(notify_obj->pci_bus);
}
- if (nd->pci_dev) {
- pci_check_pme_status(nd->pci_dev);
- pm_request_resume(&nd->pci_dev->dev);
+ if (notify_obj->pci_dev) {
+ pci_check_pme_status(notify_obj->pci_dev);
+ pm_request_resume(&notify_obj->pci_dev->dev);
}
- } else if (nd->hp_cb) {
- nd->hp_cb(handle, event, nd->hp_data);
+ } else if (notify_obj->hp_cb) {
+ notify_obj->hp_cb(handle, event, notify_obj->hp_data);
}

- out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
}

/**
- * add_notify_data - Create a new notify data object for given ACPI device.
- * @dev: Device to create the notify data object for.
+ * add_notify_obj - Create a new notify object for given ACPI handle.
+ * @handle: ACPI handle to create the notify object for.
*/
-static struct pci_acpi_notify_data *add_notify_data(struct acpi_device *dev)
+static struct pci_acpi_notify_object *add_notify_obj(acpi_handle handle)
{
- struct pci_acpi_notify_data *nd;
+ struct pci_acpi_notify_object *notify_obj;

- nd = kzalloc(sizeof(*nd), GFP_KERNEL);
- if (!nd)
+ notify_obj = kzalloc(sizeof(*notify_obj), GFP_KERNEL);
+ if (!notify_obj)
return NULL;

- dev->bus_data = nd;
- return nd;
-}
-
-/**
- * remove_notify_data - Remove the notify data object from given ACPI device.
- * @dev: Device to remove the notify data object from.
- */
-static void remove_notify_data(struct acpi_device *dev)
-{
- kfree(dev->bus_data);
- dev->bus_data = NULL;
+ notify_obj->handle = handle;
+ return notify_obj;
}

/**
* pci_acpi_add_hp_notifier - Register a hotplug notifier for given device.
- * @handle: ACPI handle of the device to register the notifier for.
+ * @handle: ACPI handle to register the notifier for.
* @handler: Callback to execute for hotplug events related to @handle.
* @context: Pointer to the context data to pass to @handler.
*
- * Use @handle to get an ACPI device object and check if there is a notify data
- * object for it. If this is the case, add @handler and @context to the
- * existing notify data object, unless there already is a hotplug handler in
- * there. Otherwise, create a new notify data object for the ACPI device
- * associated with @handle and add @handler and @context to it.
+ * Find the notify object associated with @handle or create one if not found.
+ * Return error code if the notify object already contains a valid pointer to
+ * a hotplug handler or add @handler and @context to the notify object.
*/
acpi_status pci_acpi_add_hp_notifier(acpi_handle handle,
acpi_notify_handler handler, void *context)
{
- struct pci_acpi_notify_data *nd;
- struct acpi_device *dev;
+ struct pci_acpi_notify_object *notify_obj;
acpi_status status = AE_OK;

- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev)))
- return AE_NOT_FOUND;
+ if (!handle)
+ return AE_BAD_PARAMETER;

- mutex_lock(&pci_acpi_notifier_mtx);
+ mutex_lock(&pci_acpi_notify_mtx);

- nd = dev->bus_data;
- if (nd) {
- if (!nd->hp_cb)
- goto add;
-
- status = AE_ALREADY_EXISTS;
- goto out;
- }
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle) {
+ if (notify_obj->hp_cb) {
+ status = AE_ALREADY_EXISTS;
+ goto out;
+ } else {
+ goto add;
+ }
+ }

- nd = add_notify_data(dev);
- if (!nd) {
+ notify_obj = add_notify_obj(handle);
+ if (!notify_obj) {
status = AE_NO_MEMORY;
goto out;
}

status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
- pci_acpi_event_fn, NULL);
+ pci_acpi_event_fn, notify_obj);
if (ACPI_FAILURE(status)) {
- remove_notify_data(dev);
+ kfree(notify_obj);
goto out;
}

+ list_add_tail(&notify_obj->entry, &pci_acpi_notify_list);
+
add:
- nd->hp_cb = handler;
- nd->hp_data = context;
+ notify_obj->hp_cb = handler;
+ notify_obj->hp_data = context;

out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);

return status;
}
@@ -161,38 +146,43 @@ EXPORT_SYMBOL_GPL(pci_acpi_add_hp_notifi
* @handle: ACPI handle of the device to unregister the notifier for.
* @handler: Callback executed for hotplug events related to @handle.
*
- * Remove the hotplug callback and the pointer to the hotplug context data from
- * the notify data object belonging to the device represented by @handle. If
- * the notify data object is not necessary any more, remove it altogether.
+ * Find the notify object corresponding to @handle and remove the pointers to
+ * the hotplug handler and data from it. Return error code if the notify object
+ * is not found.
*/
acpi_status pci_acpi_remove_hp_notifier(acpi_handle handle,
acpi_notify_handler handler)
{
- struct pci_acpi_notify_data *nd;
- struct acpi_device *dev;
+ struct pci_acpi_notify_object *notify_obj;
acpi_status status = AE_NOT_FOUND;

- if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, &dev)))
- return AE_NOT_FOUND;
+ if (!handle)
+ return AE_BAD_PARAMETER;

- mutex_lock(&pci_acpi_notifier_mtx);
+ mutex_lock(&pci_acpi_notify_mtx);

- nd = dev->bus_data;
- if (!nd)
- goto out;
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle)
+ goto remove;

- nd->hp_data = NULL;
- nd->hp_cb = NULL;
+ goto out;

- if (nd->pci_bus || nd->pci_dev)
+ remove:
+ notify_obj->hp_data = NULL;
+ notify_obj->hp_cb = NULL;
+
+ if (notify_obj->pci_bus || notify_obj->pci_dev) {
+ status = AE_OK;
goto out;
+ }

status = acpi_remove_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
pci_acpi_event_fn);
- remove_notify_data(dev);
+ list_del(&notify_obj->entry);
+ kfree(notify_obj);

out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
return status;
}
EXPORT_SYMBOL_GPL(pci_acpi_remove_hp_notifier);
@@ -203,14 +193,13 @@ EXPORT_SYMBOL_GPL(pci_acpi_remove_hp_not
* @pci_dev: PCI device to check for the PME status if an event is signaled.
* @pci_bus: PCI bus to walk (checking PME status) if an event is signaled.
*
- * Check if there is a notify data object for @dev and if that is the case, add
- * @pci_dev to it as the device whose PME status should be checked whenever a PM
- * event is signaled for @dev. Also, add @pci_bus to it as the bus to walk
- * checking the PME status of all devices on it whenever a PM event is signaled
- * for @dev.
- *
- * Otherwise, create a new notify data object for @dev and add both @pci_dev and
- * @pci_bus to it.
+ * Use @dev to find the notify object corresponding to its handle or create a
+ * new one if not found. Return error code if the notify object already
+ * contains a valid pointer to a PCI device or bus object. Otherwise, add
+ * @pci_dev and @pci_bus to the notify object, as the device whose PME status
+ * should be checked whenever a PM event is signaled for @dev and the bus to
+ * walk checking the PME status of all devices on it whenever a PM event is
+ * signaled for @dev, respectively.
*
* NOTE: @dev need not be a run-wake or wake-up device to be a valid source of
* PM wake-up events. For example, wake-up events may be generated for bridges
@@ -221,34 +210,46 @@ acpi_status pci_acpi_add_pm_notifier(str
struct pci_dev *pci_dev,
struct pci_bus *pci_bus)
{
- struct pci_acpi_notify_data *nd;
+ struct pci_acpi_notify_object *notify_obj;
+ acpi_handle handle = dev->handle;
acpi_status status = AE_OK;

- mutex_lock(&pci_acpi_notifier_mtx);
+ if (!handle)
+ return AE_BAD_PARAMETER;

- nd = dev->bus_data;
- if (nd)
- goto add;
+ mutex_lock(&pci_acpi_notify_mtx);

- nd = add_notify_data(dev);
- if (!nd) {
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle) {
+ if (notify_obj->pci_dev || notify_obj->pci_bus) {
+ status = AE_ALREADY_EXISTS;
+ goto out;
+ } else
+ goto add;
+ }
+ }
+
+ notify_obj = add_notify_obj(handle);
+ if (!notify_obj) {
status = AE_NO_MEMORY;
goto out;
}

- status = acpi_install_notify_handler(dev->handle, ACPI_SYSTEM_NOTIFY,
- pci_acpi_event_fn, NULL);
+ status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
+ pci_acpi_event_fn, notify_obj);
if (ACPI_FAILURE(status)) {
- remove_notify_data(dev);
+ kfree(notify_obj);
goto out;
}

+ list_add_tail(&notify_obj->entry, &pci_acpi_notify_list);
+
add:
- nd->pci_dev = pci_dev;
- nd->pci_bus = pci_bus;
+ notify_obj->pci_dev = pci_dev;
+ notify_obj->pci_bus = pci_bus;

out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
return status;
}

@@ -256,33 +257,40 @@ acpi_status pci_acpi_add_pm_notifier(str
* pci_acpi_remove_pm_notifier - Unregister PM notifier for given device.
* @dev: ACPI device to remove the notifier from.
*
- * Find the notify data object for @dev and clear its @pci_dev and @pci_bus
+ * Find the notify object for @dev and clear its @pci_dev and @pci_bus
* fields. If the notify data object is not necessary any more after that,
- * remove it too.
+ * remove it altogether.
*/
acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
{
- struct pci_acpi_notify_data *nd;
+ struct pci_acpi_notify_object *notify_obj;
+ acpi_handle handle = dev->handle;
acpi_status status = AE_NOT_FOUND;

- mutex_lock(&pci_acpi_notifier_mtx);
+ mutex_lock(&pci_acpi_notify_mtx);

- nd = dev->bus_data;
- if (!nd)
- goto out;
+ list_for_each_entry(notify_obj, &pci_acpi_notify_list, entry)
+ if (notify_obj->handle == handle)
+ goto remove;
+
+ goto out;

- nd->pci_dev = NULL;
- nd->pci_bus = NULL;
+ remove:
+ notify_obj->pci_dev = NULL;
+ notify_obj->pci_bus = NULL;

- if (nd->hp_cb)
+ if (notify_obj->hp_cb) {
+ status = AE_OK;
goto out;
+ }

status = acpi_remove_notify_handler(dev->handle, ACPI_SYSTEM_NOTIFY,
pci_acpi_event_fn);
- remove_notify_data(dev);
+ list_del(&notify_obj->entry);
+ kfree(notify_obj);

out:
- mutex_unlock(&pci_acpi_notifier_mtx);
+ mutex_unlock(&pci_acpi_notify_mtx);
return status;
}

Index: linux-2.6/include/acpi/acpi_bus.h
===================================================================
--- linux-2.6.orig/include/acpi/acpi_bus.h
+++ linux-2.6/include/acpi/acpi_bus.h
@@ -282,7 +282,6 @@ struct acpi_device {
struct device dev;
struct acpi_bus_ops bus_ops; /* workaround for different code path for hotplug */
enum acpi_bus_removal_type removal_type; /* indicate for different removal type */
- void *bus_data;
};

static inline void *acpi_driver_data(struct acpi_device *d)
--
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/

==============================================================================
TOPIC: x86: do not reserve brk for DMI if it's not going to be used
http://groups.google.com/group/linux.kernel/t/addf815261c6c6ba?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 9 2010 3:50 pm
From: Thadeu Lima de Souza Cascardo

This will save 65536 bytes from memory when loading linux, which is good
for embedded systems.

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
---
arch/x86/kernel/setup.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 3499b4f..cb42109 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -121,7 +121,9 @@
unsigned long max_low_pfn_mapped;
unsigned long max_pfn_mapped;

+#ifdef CONFIG_DMI
RESERVE_BRK(dmi_alloc, 65536);
+