From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: kristen.c.accardi@intel.com
Cc: Alex Chiang <achiang@hp.com>, Gary Hade <garyhade@us.ibm.com>,
Matthew Wilcox <matthew@wil.cx>,
gregkh@suse.de, lenb@kernel.org, rick.jones2@hp.com,
linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
pcihpd-discuss@lists.sourceforge.net, linux-acpi@vger.kernel.org
Subject: Re: [PATCH 0/4, v3] Physical PCI slot objects
Date: Wed, 12 Mar 2008 21:25:19 +0900 [thread overview]
Message-ID: <47D7CBAF.4090308@jp.fujitsu.com> (raw)
In-Reply-To: <20080311121516.42e3a727@appleyard>
Hi Kristen,
> Hello - back to this mail for a moment. I wanted to talk about acpiphp
> again. You say that acpiphp has this same problem as Alex's driver wrt
> evalating _SUN on a non existant object. If we skip registering the
> slot in acpiphp's register_slot function if it returns 0 for _STA, we
> will not detect any hotplug slots, since leaf nodes will return 0 for
> _STA if a device is not present. Should we only skip it if it's parent
> is a p2p bridge that has _EJ0 and the parent's _STA says empty?
I've been not looking at acpiphp code for a long time. So I need refresh
my memory before answering. Sorry.
But I want to say one thing. We can detect all the hotplug slots if ACPI
firmware doesn't provide _STA. We don't need _STA for PCI hotplug slots
and should not provide _STA for PCI hotplug slots if the system is based
on ACPI2.0 or later, because those are _ADR based devices (PCI root bridge,
which is _HID based device, is a exception). For _ADR based devices, we
should check the presence of the device using PCI bus drivers instead of
evaluating _STA. Please see the section of "_EJx (Eject)" in ACPI2.0b or
later spec. It says "For _HID devices, OSPM evaluates the _STA method. For
_ADR devices, OSPM checks with the bus driver for that device.".
BTW, acpiphp_glue.c says _STA is "optionally". I don't know what it means.
Thanks,
Kenji Kaneshige
Kristen Carlson Accardi wrote:
> On Thu, 29 Nov 2007 16:47:14 +0900
> Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> wrote:
>
>>> Hi Gary, Kenji-san, et. al,
>>>
>>> * Gary Hade <garyhade@us.ibm.com>:
>>>> Alex, What I was trying to suggest is a boot-time kernel
>>>> option, not a kernel configuration option. The basic idea is
>>>> to give the user (with a single binary kernel) the ability to
>>>> include your ACPI-PCI slot driver feature changes only when
>>>> they are really needed. In addition to reducing the number of
>>>> system/PCI hotplug driver combinations where your changes would
>>>> need to be validated, I believe would also help alleviate other
>>>> worries (e.g. Andi Kleen's memory consumption concern). I
>>>> believe this goal could also be achieved with the kernel config
>>>> option by making the pci_slot module runtime loadable with the
>>>> PCI hotplug drivers only visiting your new code when the
>>>> pci_slot driver is loaded, although I think this would be more
>>>> difficult to implement.
>>> I have modified my patch series so that the final patch that
>>> introduces my ACPI-PCI slot driver is a full-fledged module, that
>>> has a tristate Kconfig option.
>>>
>> Thank you for your good job.
>>
>> I tested shpchp and pciehp both with and without pci_slot module.
>> There seems no regression from shpchp and pciehp's point of view.
>> (I had a little concern about the hotplug slots' name that vary
>> depending on whether pci_slot functionality is enabled or disabled.
>> But, now that we can build pci_slot driver as a kernel module, I
>> don't think it is a big problem).
>>
>> Only the problems is that I got Call Traces with the following error
>> messages when pci_slot driver was loaded, and one strange slot named
>> '1023' was registered (other slots are fine). This is the same problem
>> I reported before.
>>
>> sysfs: duplicate filename '1023' can not be created
>> WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
>>
>> kobject_add failed for 1023 with -EEXIST, don't try to register
>> things with the same name in the same directory.
>>
>> On my system, hotplug slots themselves can be added, removed and
>> replaced with the ohter type of I/O box. The ACPI firmware tells OS
>> the presence of those slots using _STA method (That is, it doesn't
>> use 'LoadTable()' AML operator). On the other hand, current pci_slot
>> driver doesn't check _STA. As a result, pci_slot driver tryied to
>> register the invalid (non-existing) slots. The ACPI firmware of my
>> system returns '1023' if the invalid slot's _SUN is evaluated. This
>> is the cause of Call Traces mentioned above. To fix this problem,
>> pci_slot driver need to check _STA when scanning ACPI Namespace.
>>
>> I'm sorry for reporting this so late. I'm attaching the patch to fix
>> the problem. This is against 2.6.24-rc3 with your patches applied.
>> Could you try it?
>>
>> BTW, acpiphp also seems to have the same problem...
>>
>> Thanks,
>> Kenji Kaneshige
>
> Hello - back to this mail for a moment. I wanted to talk about acpiphp
> again. You say that acpiphp has this same problem as Alex's driver wrt
> evalating _SUN on a non existant object. If we skip registering the
> slot in acpiphp's register_slot function if it returns 0 for _STA, we
> will not detect any hotplug slots, since leaf nodes will return 0 for
> _STA if a device is not present. Should we only skip it if it's parent
> is a p2p bridge that has _EJ0 and the parent's _STA says empty?
>
> Your input is appreciated,
> Kristen
>
>> ---
>> drivers/acpi/pci_slot.c | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> Index: linux-2.6.24-rc3/drivers/acpi/pci_slot.c
>> ===================================================================
>> --- linux-2.6.24-rc3.orig/drivers/acpi/pci_slot.c
>> +++ linux-2.6.24-rc3/drivers/acpi/pci_slot.c
>> @@ -113,10 +113,17 @@ register_slot(acpi_handle handle, u32 lv
>> int device;
>> unsigned long sun;
>> char name[KOBJ_NAME_LEN];
>> + acpi_status status;
>> + struct acpi_device *dummy_device;
>>
>> struct pci_slot *pci_slot;
>> struct pci_bus *pci_bus = context;
>>
>> + /* Skip non-existing device object. */
>> + status = acpi_bus_get_device(handle, &dummy_device);
>> + if (ACPI_FAILURE(status))
>> + return AE_OK;
>> +
>> if (check_slot(handle, &device, &sun))
>> return AE_OK;
>>
>> @@ -150,12 +157,18 @@ walk_p2p_bridge(acpi_handle handle, u32
>> acpi_status status;
>> acpi_handle dummy_handle;
>> acpi_walk_callback user_function;
>> + struct acpi_device *dummy_device;
>>
>> struct pci_dev *dev;
>> struct pci_bus *pci_bus;
>> struct p2p_bridge_context child_context;
>> struct p2p_bridge_context *parent_context = context;
>>
>> + /* Skip non-existing device object. */
>> + status = acpi_bus_get_device(handle, &dummy_device);
>> + if (ACPI_FAILURE(status))
>> + return AE_OK;
>> +
>> pci_bus = parent_context->pci_bus;
>> user_function = parent_context->user_function;
>>
>>
>
>
prev parent reply other threads:[~2008-03-12 12:37 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-17 18:29 [PATCH 0/4, v3] Physical PCI slot objects Alex Chiang
2007-11-17 18:29 ` Alex Chiang
2007-11-17 18:35 ` [PATCH 1/4, v3] PCI Hotplug: Remove path attribute from sgi_hotplug Alex Chiang
2007-11-17 18:35 ` Alex Chiang
2007-11-17 18:35 ` [PATCH 2/4, v3] PCI Hotplug: Construct one fakephp slot per pci slot Alex Chiang
2007-11-17 18:35 ` Alex Chiang
2007-11-17 18:37 ` [PATCH 3/4, v3] PCI, PCI Hotplug: Introduce pci_slot Alex Chiang
2007-11-17 18:37 ` Alex Chiang
2007-11-19 22:03 ` [PATCH 3/4, v4] " Alex Chiang
2007-11-19 22:03 ` Alex Chiang
2007-11-17 18:38 ` [PATCH 4/4, v3] ACPI, PCI: ACPI PCI slot detection driver Alex Chiang
2007-11-17 18:38 ` Alex Chiang
[not found] ` <20071119220418.GE32540@ldl.fc.hp.com>
2007-11-19 22:26 ` [PATCH 4/4, v4] " Kristen Carlson Accardi
2007-11-20 3:07 ` Alex Chiang
2007-11-20 16:23 ` stgit (was Re: [PATCH 4/4, v4] ACPI, PCI: ACPI PCI slot detection driver) Henrique de Moraes Holschuh
2007-11-19 17:43 ` [PATCH 0/4, v3] Physical PCI slot objects Kristen Carlson Accardi
2007-11-19 17:43 ` Kristen Carlson Accardi
2007-11-19 17:57 ` Alex Chiang
2007-11-19 22:02 ` Alex Chiang
2007-11-19 23:32 ` Gary Hade
2007-11-19 23:32 ` Gary Hade
2007-11-20 1:33 ` Kenji Kaneshige
2007-11-20 2:04 ` Matthew Garrett
2007-11-20 19:53 ` Gary Hade
2007-11-26 22:22 ` Alex Chiang
2007-11-26 22:26 ` [PATCH 3/4, v5] PCI, PCI Hotplug: Introduce pci_slot Alex Chiang
2007-11-26 22:28 ` [PATCH 4/4, v5] ACPI, PCI: ACPI PCI slot detection driver Alex Chiang
2007-11-27 3:04 ` [PATCH 0/4, v3] Physical PCI slot objects Gary Hade
2007-11-27 19:11 ` Kristen Carlson Accardi
2007-11-27 19:11 ` Kristen Carlson Accardi
2007-11-28 21:31 ` Gary Hade
2007-11-29 0:02 ` Kristen Carlson Accardi
2007-11-29 0:02 ` Kristen Carlson Accardi
2007-11-29 1:09 ` Gary Hade
2007-11-30 1:19 ` Alex Chiang
2007-11-30 19:10 ` Gary Hade
2007-11-29 7:47 ` Kenji Kaneshige
2007-11-29 7:47 ` Kenji Kaneshige
2007-11-30 1:51 ` Alex Chiang
2007-12-03 3:30 ` Kenji Kaneshige
2007-12-03 22:43 ` Alex Chiang
2007-12-04 12:57 ` Kenji Kaneshige
2007-12-04 12:57 ` Kenji Kaneshige
2007-12-10 23:02 ` Alex Chiang
2008-03-11 19:15 ` Kristen Carlson Accardi
2008-03-11 19:15 ` Kristen Carlson Accardi
2008-03-12 12:25 ` Kenji Kaneshige [this message]
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=47D7CBAF.4090308@jp.fujitsu.com \
--to=kaneshige.kenji@jp.fujitsu.com \
--cc=achiang@hp.com \
--cc=garyhade@us.ibm.com \
--cc=gregkh@suse.de \
--cc=kristen.c.accardi@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=matthew@wil.cx \
--cc=pcihpd-discuss@lists.sourceforge.net \
--cc=rick.jones2@hp.com \
/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.