[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFy7PvVqAN6tLFFuCUALsXsKsuf-yqWso3aZGe4-MkFvuw@mail.gmail.com>
Date: Tue, 26 Feb 2013 08:13:40 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Yinghai Lu <yinghai@...nel.org>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
"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 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...
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists