All of lore.kernel.org
 help / color / mirror / Atom feed
From: Moore, Robert <robert.moore at intel.com>
To: devel@acpica.org
Subject: Re: [Devel] Error in documentation of AcpiOsDerivePciId?
Date: Tue, 20 Apr 2010 09:10:30 -0700	[thread overview]
Message-ID: <4911F71203A09E4D9981D27F9D830858622A0BCF@orsmsx503.amr.corp.intel.com> (raw)
In-Reply-To: 4BCDD134.5060508@gmail.com

[-- Attachment #1: Type: text/plain, Size: 4642 bytes --]

Yes, It looks like there may be more to this than it first appeared. I haven't looked at the DerivePciId interface for some time.

I'm not fully sure what RegionObj->Region.Node refers to. I will investigate further.

Bob

>-----Original Message-----
>From: Grégoire Sutre [mailto:gregoire.sutre(a)gmail.com]
>Sent: Tuesday, April 20, 2010 9:07 AM
>To: Moore, Robert
>Cc: devel(a)acpica.org
>Subject: Re: [Devel] Error in documentation of AcpiOsDerivePciId?
>
>Hi Robert,
>
>First I want to thank you for your answer.
>
>> It looks to me that the documentation (ACPICA programmer reference) is
>correct.
>>
>> However, the acpiosxf.h file uses names that don't match the
>documentation and are not very descriptive.
>>
>> The ACPICA code uses a variable named "PciRootNode" for the
>"DeviceHandle" parameter, that is ok.
>
>The call to AcpiOsDerivePciId that I mentioned is performed in the
>function AcpiEvPciConfigRegionSetup of events/evrgnini.c.  Looking at
>this function (from acpica unix source code release 20100331), I see
>that:
>
>- RegionObj->Region.Node is the PCI device node that we are interested
>   in.  This is confirmed by the part that finds the parent device
>   object, which starts with:
>   PciDeviceNode = RegionObj->Region.Node;
>
>- PciRootNode is the PCI root bridge upstream of the PCI device node
>   that we are interested in.  Indeed, there is a while-loop that walks
>   the ancestors of the PCI device node until a PCI root bridge is found,
>   iteratively assigning PciRootNode to these ancestors.  See lines 312
>   to 360.
>
>This is the reason why I believe that in the call
>
>AcpiOsDerivePciId (PciRootNode, RegionObj->Region.Node, &PciId);
>
>- PciRootNode is not a handle to the PCI device, it is a handle to its
>   upstream PCI root bridge, and
>- RegionObj->Region.Node is a handle to the PCI device.
>
>>> So it seems to me that the correct arguments for AcpiOsDerivePciId are:
>>
>>> AcpiOsDerivePciId(
>>>    ACPI_HANDLE		PciRootHandle
>>>    ACPI_HANDLE		DeviceHandle
>>>    ACPI_PCI_ID		**PciId)
>>
>>
>> No, I don't think so. The second parameter is a handle to a region
>object.
>
>In the above call to AcpiOsDerivePciId, the second parameter, which is
>RegionObj->Region.Node, is of type (ACPI_NAMESPACE_NODE *).  I'm not
>familiar with all the ACPI types, but I guess that this type is not for
>region objects.
>
>Note that the implementation of AcpiOsDerivePciId in the linux kernel
>(as well as in the freebsd and netbsd kernels) seem to understand its
>interface in the same way as I did.
>
>http://lxr.linux.no/#linux+v2.6.33/drivers/acpi/osl.c#L689
>
>Best regards,
>
>Grégoire
>
>>> -----Original Message-----
>>> From: devel-bounces(a)acpica.org [mailto:devel-bounces(a)acpica.org] On
>Behalf
>>> Of Grégoire Sutre
>>> Sent: Tuesday, April 20, 2010 2:46 AM
>>> To: devel(a)acpica.org
>>> Subject: [Devel] Error in documentation of AcpiOsDerivePciId?
>>>
>>> Hi list,
>>>
>>> According to the ACPICA Programmer Reference, the function
>>> AcpiOsDerivePciId takes as arguments:
>>>
>>> AcpiOsDerivePciId(
>>>    ACPI_HANDLE		DeviceHandle
>>>    ACPI_HANDLE		PciRegionHandle
>>>    ACPI_PCI_ID		**PciId)
>>>
>>> with:
>>> - DeviceHandle:		a handle to the PCI device.
>>> - PciRegionHandle:	a handle the PCI configuration space operation
>>>                         region.
>>>
>>>
>>> However, the only call to AcpiOsDerivePciId in the ACPICA code, in
>>> events/evrgnini.c, is:
>>>
>>> AcpiOsDerivePciId (PciRootNode, RegionObj->Region.Node, &PciId);
>>>
>>> Moreover, the file include/acpiosxf.h contains:
>>>
>>> /*
>>>  * Interim function needed for PCI IRQ routing
>>>  */
>>> void
>>> AcpiOsDerivePciId(
>>>     ACPI_HANDLE             Rhandle,
>>>     ACPI_HANDLE             Chandle,
>>>     ACPI_PCI_ID             **PciId);
>>>
>>>
>>> So it seems to me that the correct arguments for AcpiOsDerivePciId are:
>>>
>>> AcpiOsDerivePciId(
>>>    ACPI_HANDLE		PciRootHandle
>>>    ACPI_HANDLE		DeviceHandle
>>>    ACPI_PCI_ID		**PciId)
>>>
>>> with:
>>> - PciRootHandle:	a handle the PCI root bridge upstream of the PCI
>>>                         device (or to the name space root node if no
>>>                         PCI root bridge was found in the ancestors).
>>> - DeviceHandle:		a handle to the PCI device.
>>>
>>>
>>> Is that correct?
>>>
>>> Thanks for your help,
>>>
>>> Grégoire
>>> _______________________________________________
>>> Devel mailing list
>>> Devel(a)acpica.org
>>> http://lists.acpica.org/listinfo/devel


             reply	other threads:[~2010-04-20 16:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-20 16:10 Moore, Robert [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-08-04 23:33 [Devel] Error in documentation of AcpiOsDerivePciId? Moore, Robert
2010-08-04 21:36 Moore, Robert
2010-08-02  0:29 Lin Ming
2010-08-01 11:31 Rudi
2010-04-23 12:44 Lin Ming
2010-04-22 12:50 
2010-04-21 23:33 Lin Ming
2010-04-20 16:07 
2010-04-20 14:51 Moore, Robert
2010-04-20  9:45 

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4911F71203A09E4D9981D27F9D830858622A0BCF@orsmsx503.amr.corp.intel.com \
    --to=devel@acpica.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.