On Tue, 2013-08-06 at 02:15 +0200, Rafael J. Wysocki wrote:
> On Monday, August 05, 2013 05:19:56 PM Toshi Kani wrote:
> > 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.wyso...@intel.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.wyso...@intel.com>
> > 
> > I like the change. Much better :-)
> > 
> > Acked-by: Toshi Kani <toshi.k...@hp.com>
> 
> However, it introduces a bug in acpi_unbind_one(), because the size of the 
> name
> array in there has to be increased too.  Updated patch follows.

Right.  Sorry, I overlooked this one.  Please apply my ask to this new
version. 

Thanks,
-Toshi

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

Reply via email to