[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1375744796.10300.175.camel@misato.fc.hp.com>
Date: Mon, 05 Aug 2013 17:19:56 -0600
From: Toshi Kani <toshi.kani@...com>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
rafael.j.wysocki@...el.com, vasilis.liaskovitis@...fitbricks.com,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
tangchen@...fujitsu.com, wency@...fujitsu.com
Subject: Re: Cannot hot remove a memory device (patch)
On Mon, 2013-08-05 at 15:14 +0200, Rafael J. Wysocki wrote:
:
> Can you please test the appended patch? I tested it somewhat, but since the
> greatest number of physical nodes per ACPI device object I can get on my test
> machines is 2 (and even that after hacking the kernel somewhat), that was kind
> of unconclusive.
>
> Thanks,
> Rafael
>
>
> ---
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> Subject: ACPI: Drop physical_node_id_bitmap from struct acpi_device
>
> The physical_node_id_bitmap in struct acpi_device is only used for
> looking up the first currently unused phyiscal dependent node ID
> by acpi_bind_one(). It is not really necessary, however, because
> acpi_bind_one() walks the entire physical_node_list of the given
> device object for sanity checking anyway and if that list is always
> sorted by node_id, it is straightforward to find the first gap
> between the currently used node IDs and use that number as the ID
> of the new list node.
>
> This also removes the artificial limit of the maximum number of
> dependent physical devices per ACPI device object, which now depends
> only on the capacity of unsigend int.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
I like the change. Much better :-)
Acked-by: Toshi Kani <toshi.kani@...com>
Thanks,
-Toshi
--
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