[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE9FiQUkMqqSE9JJuxt7MxLheQA1j2nKC7QfOB7xLEJ9iUhs7g@mail.gmail.com>
Date: Tue, 26 Feb 2013 10:14:29 -0800
From: Yinghai Lu <yinghai@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J. Wysocki" <rjw@...k.pl>
Cc: "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] PCI changes for v3.9
On Tue, Feb 26, 2013 at 8:13 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Mon, Feb 25, 2013 at 10:46 PM, Yinghai Lu <yinghai@...nel.org> wrote:
>> On Mon, Feb 25, 2013 at 9:19 PM, Linus Torvalds
>> <torvalds@...ux-foundation.org> wrote:
>>>
>>> Also, my *gut* feel is that the new _handle_hotplug_event_root()
>>> function should do that whole dance with
>>> acpi_scan_lock_acquire()/acpi_scan_lock_release(), but I didn't really
>>> know if it's required or appropriate, so I left it alone. Could you
>>> take a look?
>>
>> Yes, we need that for root bridge hot add path.
>>
>> for hot remove path, we already have lock acquire/release in
>> acpi_bus_hot_remove_device().
>>
>> Please check attached patch for hot add path.
>
> Quite frankly, doing this in handle_root_bridge_insertion() doesn't
> match the pattern elsewhere. Elsewhere you also protected the whole
> acpi_get_name() lookup etc. Which is why I felt that it would make
> more sense to add this to _handle_hotplug_event_root().
>
> But there may be good reasons why the root bridge case is different,
> and I don't have strong opinions, I just wanted people to look at his
> case. I'll let you and Bjorn sort it out...
ok,
Bjorn, Rafael,
Can you please check if you are ok with attached patch ?
Thanks
Yinghai
Download attachment "fix_acpi_pci_root_acquire_lock.patch" of type "application/octet-stream" (1963 bytes)
Powered by blists - more mailing lists