Linux/ACPI 2.4 release status

Linux/ACPI 2.4 release status

[Len Brown]

Folks,
2.4.23 shipped -- and I'd like to thank all of you for helping build the
best stable ACPI kernel yet!

There is a new 2.4.24 BK tree on bkbits and corresponding patch
directory on kernel.org (below).  The latest ACPI patch integrated with
2.4.24 will live there.  At the same time, I'll also export the latest
ACPI patch backported to the 2.4.22 and 2.4.23 BK trees and patch
directories.

The latest patch (below) contains two ACPICA updates, as well as a
handful of other patches.  Please try it out and let me know how it
goes.

Yes, this is a good time to remind me about, or update and re-send
patches that we were not able to handle in time for 2.4.23.

thanks,
-Len
----

bk pull http://linux-acpi.bkbits.net/linux-acpi-release-2.4.24
or
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.4.24-pre1/acpi-20031203-2.4.24-pre1.diff.gz

This will update the following files:

 arch/i386/kernel/mpparse.c         |    8 -
 arch/i386/kernel/smpboot.c         |    2 
 drivers/acpi/Config.in             |    3 
 drivers/acpi/dispatcher/dsinit.c   |    4 
 drivers/acpi/dispatcher/dsmethod.c |    4 
 drivers/acpi/dispatcher/dsmthdat.c |   45 ++++--
 drivers/acpi/dispatcher/dsopcode.c |   22 +-
 drivers/acpi/dispatcher/dswexec.c  |   22 ++
 drivers/acpi/dispatcher/dswload.c  |    8 -
 drivers/acpi/dispatcher/dswscope.c |    8 -
 drivers/acpi/events/evgpe.c        |   59 +++-----
 drivers/acpi/events/evgpeblk.c     |    5 
 drivers/acpi/events/evmisc.c       |    3 
 drivers/acpi/events/evregion.c     |  134 ++++++++++++------
 drivers/acpi/events/evrgnini.c     |   32 +++-
 drivers/acpi/events/evxfregn.c     |   24 ++-
 drivers/acpi/executer/exdump.c     |   50 +++---
 drivers/acpi/executer/exfldio.c    |  184 ++++++++++++-------------
 drivers/acpi/executer/exmisc.c     |    6 
 drivers/acpi/executer/exmutex.c    |   12 -
 drivers/acpi/executer/exoparg1.c   |    3 
 drivers/acpi/executer/exoparg3.c   |    5 
 drivers/acpi/executer/exprep.c     |    4 
 drivers/acpi/executer/exregion.c   |   10 -
 drivers/acpi/executer/exresolv.c   |    6 
 drivers/acpi/executer/exresop.c    |    4 
 drivers/acpi/executer/exstore.c    |    3 
 drivers/acpi/executer/exsystem.c   |   21 ++
 drivers/acpi/hardware/hwacpi.c     |   13 -
 drivers/acpi/hardware/hwregs.c     |   12 -
 drivers/acpi/hardware/hwsleep.c    |   89 ++++++++----
 drivers/acpi/namespace/nsaccess.c  |    8 -
 drivers/acpi/namespace/nsalloc.c   |    7 
 drivers/acpi/namespace/nsdump.c    |   37 ++---
 drivers/acpi/namespace/nsdumpdv.c  |    2 
 drivers/acpi/namespace/nsinit.c    |   63 +++++---
 drivers/acpi/namespace/nsobject.c  |    7 
 drivers/acpi/namespace/nssearch.c  |    4 
 drivers/acpi/namespace/nsutils.c   |    6 
 drivers/acpi/namespace/nsxfname.c  |    2 
 drivers/acpi/parser/psargs.c       |    4 
 drivers/acpi/parser/psparse.c      |    4 
 drivers/acpi/parser/psxface.c      |   34 +++-
 drivers/acpi/processor.c           |   73 ++++++++-
 drivers/acpi/resources/rscalc.c    |    4 
 drivers/acpi/resources/rscreate.c  |    2 
 drivers/acpi/resources/rsdump.c    |   18 --
 drivers/acpi/resources/rsirq.c     |   38 ++---
 drivers/acpi/resources/rslist.c    |    4 
 drivers/acpi/tables.c              |   30 ++--
 drivers/acpi/tables/tbget.c        |   10 -
 drivers/acpi/tables/tbgetall.c     |    3 
 drivers/acpi/tables/tbrsdt.c       |    3 
 drivers/acpi/tables/tbxface.c      |    2 
 drivers/acpi/tables/tbxfroot.c     |    3 
 drivers/acpi/thermal.c             |    1 
 drivers/acpi/utilities/utalloc.c   |   55 -------
 drivers/acpi/utilities/utdebug.c   |    2 
 drivers/acpi/utilities/utdelete.c  |    4 
 drivers/acpi/utilities/uteval.c    |    4 
 drivers/acpi/utilities/utglobal.c  |   99 +++++++++++++
 drivers/acpi/utilities/utobject.c  |   28 ---
 include/acpi/acconfig.h            |    4 
 include/acpi/acevents.h            |   11 +
 include/acpi/acglobal.h            |    3 
 include/acpi/acmacros.h            |   27 +--
 include/acpi/acobject.h            |   35 ++--
 include/acpi/acutils.h             |    8 +
 68 files changed, 884 insertions(+), 570 deletions(-)

through these ChangeSets:

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/11 1.1063.46.61)
   [ACPI] Update Linux to ACPICA 20031203 (Bob Moore)
   
   Changed the initialization of Operation Regions during subsystem init
to
   perform two entire walks of the ACPI namespace; The first to
initialize
   the regions themselves, the second to execute the _REG methods.  This
   fixed some interdependencies across _REG methods found on some
machines.
   
   Fixed a problem where a Store(Local0, Local1) could simply update the
   object reference count, and not create a new copy of the object if
the
   Local1 is uninitialized.
   
   Implemented support for the _SST reserved method during sleep
   transitions.
   
   Implemented support to clear the SLP_TYP and SLP_EN bits when waking
up,
   this is apparently required by some machines.
   
   When sleeping, clear the wake status only if SleepState is not S5.
   
   Fixed a problem in AcpiRsExtendedIrqResource() where an incorrect
   pointer arithmetic advanced a string pointer too far.
   
   Fixed a problem in AcpiTbGetTablePtr() where a garbage pointer could
be
   returned if the requested table has not been loaded.
   
   Within the support for IRQ resources, restructured the handling of
the
   active and edge/level bits.
   
   Fixed a few problems in AcpiPsxExecute() where memory could be leaked
   under certain error conditions.
   
   Improved error messages for the cases where the ACPI mode could not
be
   entered.

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/11 1.1063.46.60)
   [ACPI] update Linux to ACPICA 20031029 (Bob Moore)
   
   Fixed a problem where a level-triggered GPE with an associated _Lxx
   control method was incorrectly cleared twice.
   
   Fixed a problem with the Field support code where an access can occur
   beyond the end-of-region if the field is non-aligned but extends to
the
   very end of the parent region (resulted in an AE_AML_REGION_LIMIT
   exception.)
   
   Fixed a problem with ACPI Fixed Events where an RT Clock handler
would
   not get invoked on an RTC event.  The RTC event bitmasks for the PM1
   registers were not being initialized properly.
   
   Implemented support for executing _STA and _INI methods for Processor
   objects.  Although this is currently not part of the ACPI
specification,
   there is existing ASL code that depends on the init-time execution of
   these methods.
   
   Implemented and deployed a GetDescriptorName function to decode the
   various types of internal descriptors.  Guards against null
descriptors
   during debug output also.
   
   Implemented and deployed a GetNodeName function to extract the
   4-character namespace node name.  This function simplifies the debug
and
   error output, as well as guarding against null pointers during
output.
   
   Implemented and deployed the ACPI_FORMAT_UINT64 helper macro to
simplify
   the debug and error output of 64-bit integers.  This macro replaces
the
   HIDWORD and LODWORD macros for dumping these integers.
   
   Updated the implementation of the Stall() operator to only call
   AcpiOsStall(), and also return an error if the operand is larger than
   255.  This preserves the required behavior of not relinquishing the
   processor, as would happen if AcpiOsSleep() was called for "long
   stalls".
   
   Constructs of the form "Store(LocalX,LocalX)" where LocalX is not
   initialized are now treated as NOOPs.
   
   Cleaned up a handful of warnings during 64-bit generation.
   
   Fixed a reported error where and incorrect GPE number was passed to
the
   GPE dispatch handler.  This value is only used for error output,
   however.  Used this opportunity to clean up and streamline the GPE
   dispatch code.

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/11 1.1063.46.59)
   [ACPI] revert two fixes in preparation for ACPICA merge

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/10 1.1063.46.58)
   [ACPI] set APIC ACPI SCI OVR default to level/low
     http://bugzilla.kernel.org/show_bug.cgi?id=1351

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/10 1.1063.46.57)
   [ACPI] change hard-coded IO width to programmable width (Shaohua
David Li)
     http://bugzilla.kernel.org/show_bug.cgi?id=1349

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/02 1.1063.46.56)
   [ACPI] add warning to thermal shutdown (Pavel Machek)

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/12/02 1.1063.46.55)
   [ACPI] handle sparse APIC-IDs in the face of reduced NR_CPUS

<len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (03/11/20 1.1063.46.54)
   [ACPI]  fix xconfig failure (Matt Wilcox)
   http://bugzilla.kernel.org/show_bug.cgi?id=1568
   






-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[Sérgio Monteiro Basto]

Hi Len


On Fri, 2003-12-12 at 06:15, Len Brown wrote:
> Folks,
> 2.4.23 shipped -- and I'd like to thank all of you for helping build the
> best stable ACPI kernel yet!

yes in my laptop it is very stable too. thanks


> Yes, this is a good time to remind me about, or update and re-send
> patches that we were not able to handle in time for 2.4.23.
> 

have you any plan? to integrated cpufreq that cames in 2.22-ac4 kernels.
or does anybody have any implantation of cpufreq for kernel 2.4.23? 

-- 
Sérgio M B




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[Karol Kozimor]

Thus wrote Sérgio Monteiro Basto:
> have you any plan? to integrated cpufreq that cames in 2.22-ac4 kernels.
> or does anybody have any implantation of cpufreq for kernel 2.4.23? 

Current snapshots of CPUFreq (both for 2.4 and 2.6) can be found here:
http://ftp.linux.org.uk/pub/linux/cpufreq/

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status and cpufreq

[Ducrot Bruno]

On Fri, Dec 12, 2003 at 05:06:24PM +0000, Sérgio Monteiro Basto wrote:
> Hi Len
> 
> 
> On Fri, 2003-12-12 at 06:15, Len Brown wrote:
> > Folks,
> > 2.4.23 shipped -- and I'd like to thank all of you for helping build the
> > best stable ACPI kernel yet!
> 
> yes in my laptop it is very stable too. thanks
> 
> 
> > Yes, this is a good time to remind me about, or update and re-send
> > patches that we were not able to handle in time for 2.4.23.
> > 
> 
> have you any plan? to integrated cpufreq that cames in 2.22-ac4 kernels.
> or does anybody have any implantation of cpufreq for kernel 2.4.23? 
> 

I don't think it's up to acpi folks to integrate cpufreq.  The 2 works
are definitely different due to the fact that cpufreq claims at
first to be architecture independant (you have to consider arm, sparc,
ppc...).

Of course, an ACPI based cpufreq driver for 2.4 will be fine, and perhaps
an acpi governor based both on input from thermal stuff, load of the system
may be good, who knows.

Note that acpi use cpufreq api in 2.[56].

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status

[Bjorn Helgaas]

On Thursday 11 December 2003 11:15 pm, Len Brown wrote:
> Yes, this is a good time to remind me about, or update and re-send
> patches that we were not able to handle in time for 2.4.23.

Here's one:

This patch against the current 2.4 tree removes a bunch of
ill-advised code I added to get _TRA information from PCI
root bridges.

This was the wrong approach because for one thing, it only
handled one MEM window and one IO window, and root bridges
may have several of each.

This patch can be applied for both 2.4 and 2.5.  ia64 was the
only user of this code, and we no longer need it.  The current
approach is to walk the _CRS in pcibios_scan_root() using
acpi_walk_resources(). 

diff -u -ur 2.4/drivers/acpi/pci_root.c 2.4-patched/drivers/acpi/pci_root.c
--- 2.4/drivers/acpi/pci_root.c	2003-12-15 11:41:51.000000000 -0700
+++ 2.4-patched/drivers/acpi/pci_root.c	2003-12-15 11:41:19.000000000 -0700
@@ -61,8 +61,6 @@
 	acpi_handle		handle;
 	struct acpi_pci_id	id;
 	struct pci_bus		*bus;
-	u64			mem_tra;
-	u64			io_tra;
 };
 
 static LIST_HEAD(acpi_pci_roots);
@@ -114,97 +112,6 @@
 	}
 }
 
-void
-acpi_pci_get_translations (
-	struct acpi_pci_id	*id,
-	u64			*mem_tra,
-	u64			*io_tra)
-{
-	struct list_head	*node = NULL;
-	struct acpi_pci_root	*entry;
-
-	/* TBD: Locking */
-	list_for_each(node, &acpi_pci_roots) {
-		entry = list_entry(node, struct acpi_pci_root, node);
-		if ((id->segment == entry->id.segment)
-			&& (id->bus == entry->id.bus)) {
-			*mem_tra = entry->mem_tra;
-			*io_tra = entry->io_tra;
-			return;
-		}
-	}
-
-	*mem_tra = 0;
-	*io_tra = 0;
-}
-
-
-static u64
-acpi_pci_root_bus_tra (
-       struct acpi_resource	*resource,
-       int			type)
-{
-	struct acpi_resource_address16 *address16;
-	struct acpi_resource_address32 *address32;
-	struct acpi_resource_address64 *address64;
-
-	while (1) {
-		switch (resource->id) {
-		case ACPI_RSTYPE_END_TAG:
-			return 0;
-
-		case ACPI_RSTYPE_ADDRESS16:
-			address16 = (struct acpi_resource_address16 *) &resource->data;
-			if (type == address16->resource_type) {
-				return address16->address_translation_offset;
-			}
-			break;
-
-		case ACPI_RSTYPE_ADDRESS32:
-			address32 = (struct acpi_resource_address32 *) &resource->data;
-			if (type == address32->resource_type) {
-				return address32->address_translation_offset;
-			}
-			break;
-
-		case ACPI_RSTYPE_ADDRESS64:
-			address64 = (struct acpi_resource_address64 *) &resource->data;
-			if (type == address64->resource_type) {
-				return address64->address_translation_offset;
-			}
-			break;
-		}
-		resource = ACPI_PTR_ADD (struct acpi_resource,
-				resource, resource->length);
-	}
-
-	return 0;
-}
-
-
-static int
-acpi_pci_evaluate_crs (
-	struct acpi_pci_root	*root)
-{
-	acpi_status		status;
-	struct acpi_buffer	buffer = {ACPI_ALLOCATE_BUFFER, NULL};
-
-	ACPI_FUNCTION_TRACE("acpi_pci_evaluate_crs");
-
-	status = acpi_get_current_resources (root->handle, &buffer);
-	if (ACPI_FAILURE(status))
-		return_VALUE(-ENODEV);
-
-	root->io_tra = acpi_pci_root_bus_tra ((struct acpi_resource *)
-			buffer.pointer, ACPI_IO_RANGE);
-	root->mem_tra = acpi_pci_root_bus_tra ((struct acpi_resource *)
-			buffer.pointer, ACPI_MEMORY_RANGE);
-
-	acpi_os_free(buffer.pointer);
-	return_VALUE(0);
-}
-
-
 static int
 acpi_pci_root_add (
 	struct acpi_device	*device)
@@ -289,10 +196,8 @@
 	root->id.function = device->pnp.bus_address & 0xFFFF;
 
 	/*
-	 * Evaluate _CRS to get root bridge resources
 	 * TBD: Need PCI interface for enumeration/configuration of roots.
 	 */
- 	acpi_pci_evaluate_crs(root);
 
  	/* TBD: Locking */
  	list_add_tail(&root->node, &acpi_pci_roots);
diff -u -ur 2.4/include/acpi/acpi_drivers.h 2.4-patched/include/acpi/acpi_drivers.h
--- 2.4/include/acpi/acpi_drivers.h	2003-12-15 11:41:53.000000000 -0700
+++ 2.4-patched/include/acpi/acpi_drivers.h	2003-12-15 11:41:19.000000000 -0700
@@ -162,7 +162,6 @@
 
 int acpi_pci_root_init (void);
 void acpi_pci_root_exit (void);
-void acpi_pci_get_translations (struct acpi_pci_id* id, u64* mem_tra, u64* io_tra);
 
 /* ACPI PCI Interrupt Link (pci_link.c) */
 



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status

[Len Brown]

Bjorn.

Is it possible that some ia32 or x86_64 platforms might depend on this
code and miss it because they lack the _CRS walk that ia64 has in
pcibios_scan_root()?


thanks,
-Len

On Mon, 2003-12-15 at 13:46, Bjorn Helgaas wrote:
> On Thursday 11 December 2003 11:15 pm, Len Brown wrote:
> > Yes, this is a good time to remind me about, or update and re-send
> > patches that we were not able to handle in time for 2.4.23.
> 
> Here's one:
> 
> This patch against the current 2.4 tree removes a bunch of
> ill-advised code I added to get _TRA information from PCI
> root bridges.
> 
> This was the wrong approach because for one thing, it only
> handled one MEM window and one IO window, and root bridges
> may have several of each.
> 
> This patch can be applied for both 2.4 and 2.5.  ia64 was the
> only user of this code, and we no longer need it.  The current
> approach is to walk the _CRS in pcibios_scan_root() using
> acpi_walk_resources(). 
> 
> diff -u -ur 2.4/drivers/acpi/pci_root.c 2.4-patched/drivers/acpi/pci_root.c
> --- 2.4/drivers/acpi/pci_root.c	2003-12-15 11:41:51.000000000 -0700
> +++ 2.4-patched/drivers/acpi/pci_root.c	2003-12-15 11:41:19.000000000 -0700
> @@ -61,8 +61,6 @@
>  	acpi_handle		handle;
>  	struct acpi_pci_id	id;
>  	struct pci_bus		*bus;
> -	u64			mem_tra;
> -	u64			io_tra;
>  };
>  
>  static LIST_HEAD(acpi_pci_roots);
> @@ -114,97 +112,6 @@
>  	}
>  }
>  
> -void
> -acpi_pci_get_translations (
> -	struct acpi_pci_id	*id,
> -	u64			*mem_tra,
> -	u64			*io_tra)
> -{
> -	struct list_head	*node = NULL;
> -	struct acpi_pci_root	*entry;
> -
> -	/* TBD: Locking */
> -	list_for_each(node, &acpi_pci_roots) {
> -		entry = list_entry(node, struct acpi_pci_root, node);
> -		if ((id->segment == entry->id.segment)
> -			&& (id->bus == entry->id.bus)) {
> -			*mem_tra = entry->mem_tra;
> -			*io_tra = entry->io_tra;
> -			return;
> -		}
> -	}
> -
> -	*mem_tra = 0;
> -	*io_tra = 0;
> -}
> -
> -
> -static u64
> -acpi_pci_root_bus_tra (
> -       struct acpi_resource	*resource,
> -       int			type)
> -{
> -	struct acpi_resource_address16 *address16;
> -	struct acpi_resource_address32 *address32;
> -	struct acpi_resource_address64 *address64;
> -
> -	while (1) {
> -		switch (resource->id) {
> -		case ACPI_RSTYPE_END_TAG:
> -			return 0;
> -
> -		case ACPI_RSTYPE_ADDRESS16:
> -			address16 = (struct acpi_resource_address16 *) &resource->data;
> -			if (type == address16->resource_type) {
> -				return address16->address_translation_offset;
> -			}
> -			break;
> -
> -		case ACPI_RSTYPE_ADDRESS32:
> -			address32 = (struct acpi_resource_address32 *) &resource->data;
> -			if (type == address32->resource_type) {
> -				return address32->address_translation_offset;
> -			}
> -			break;
> -
> -		case ACPI_RSTYPE_ADDRESS64:
> -			address64 = (struct acpi_resource_address64 *) &resource->data;
> -			if (type == address64->resource_type) {
> -				return address64->address_translation_offset;
> -			}
> -			break;
> -		}
> -		resource = ACPI_PTR_ADD (struct acpi_resource,
> -				resource, resource->length);
> -	}
> -
> -	return 0;
> -}
> -
> -
> -static int
> -acpi_pci_evaluate_crs (
> -	struct acpi_pci_root	*root)
> -{
> -	acpi_status		status;
> -	struct acpi_buffer	buffer = {ACPI_ALLOCATE_BUFFER, NULL};
> -
> -	ACPI_FUNCTION_TRACE("acpi_pci_evaluate_crs");
> -
> -	status = acpi_get_current_resources (root->handle, &buffer);
> -	if (ACPI_FAILURE(status))
> -		return_VALUE(-ENODEV);
> -
> -	root->io_tra = acpi_pci_root_bus_tra ((struct acpi_resource *)
> -			buffer.pointer, ACPI_IO_RANGE);
> -	root->mem_tra = acpi_pci_root_bus_tra ((struct acpi_resource *)
> -			buffer.pointer, ACPI_MEMORY_RANGE);
> -
> -	acpi_os_free(buffer.pointer);
> -	return_VALUE(0);
> -}
> -
> -
>  static int
>  acpi_pci_root_add (
>  	struct acpi_device	*device)
> @@ -289,10 +196,8 @@
>  	root->id.function = device->pnp.bus_address & 0xFFFF;
>  
>  	/*
> -	 * Evaluate _CRS to get root bridge resources
>  	 * TBD: Need PCI interface for enumeration/configuration of roots.
>  	 */
> - 	acpi_pci_evaluate_crs(root);
>  
>   	/* TBD: Locking */
>   	list_add_tail(&root->node, &acpi_pci_roots);
> diff -u -ur 2.4/include/acpi/acpi_drivers.h 2.4-patched/include/acpi/acpi_drivers.h
> --- 2.4/include/acpi/acpi_drivers.h	2003-12-15 11:41:53.000000000 -0700
> +++ 2.4-patched/include/acpi/acpi_drivers.h	2003-12-15 11:41:19.000000000 -0700
> @@ -162,7 +162,6 @@
>  
>  int acpi_pci_root_init (void);
>  void acpi_pci_root_exit (void);
> -void acpi_pci_get_translations (struct acpi_pci_id* id, u64* mem_tra, u64* io_tra);
>  
>  /* ACPI PCI Interrupt Link (pci_link.c) */
>  
> 



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Linux/ACPI 2.4 release status

[Bjorn Helgaas]

On Monday 15 December 2003 3:50 pm, Len Brown wrote:
> Is it possible that some ia32 or x86_64 platforms might depend on this
> code and miss it because they lack the _CRS walk that ia64 has in
> pcibios_scan_root()?

There are no current users of this code in the standard tree,
according to grep.  And the code is broken in the sense that
it only handles a single MEM and a single IO window, and bridges
often have several MEM windows.

Bjorn



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/