Merge branch 'acpi-cleanup-next' into acpi-pci-hotplug-next

Subsequent commits depend on the 'acpi-cleanup-next' material.
x86/PCI: prevent re-allocation of already existing bridge and ROM resources

In hotplug case (especially with Thunderbolt enabled systems) we might need
to call pcibios_resource_survey_bus() several times for a bus. The function
ends up calling pci_claim_resource() for each bridge resource that then
fails claiming that the resource exists already (which it does). Once this
happens the resource is invalidated thus preventing devices behind the
bridge to allocate their resources.

To fix this we do what has been done in pcibios_allocate_dev_resources()
and check 'parent' of the given resource. If it is non-NULL it means that
the resource has been allocated already and we can skip it. We do the same
for ROM resources as well.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / PCI: Make bus registration and unregistration symmetric

Since acpi_pci_slot_enumerate() and acpiphp_enumerate_slots() can get
the ACPI device handle they need from bus->bridge, it is not
necessary to pass that handle to them as an argument.

Drop the second argument of acpi_pci_slot_enumerate() and
acpiphp_enumerate_slots(), rework them to obtain the ACPI handle
from bus->bridge and make acpi_pci_add_bus() and
acpi_pci_remove_bus() entirely symmetrical.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Consolidate acpiphp_enumerate_slots()

The acpiphp_enumerate_slots() function is now split into two parts,
acpiphp_enumerate_slots() proper and init_bridge_misc() which is
only called by the former.  If these functions are combined,
it is possible to make the code easier to follow and to clean up
the error handling (to prevent memory leaks on error from
happening in particular), so do that.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Always return success after adding a function

When a new ACPIPHP function is added by register_slot() and the
notify handler cannot be installed for it, register_slot() returns an
error status without cleaning up, which causes the entire namespace
walk in acpiphp_enumerate_slots() to be aborted, although it still
may be possible to successfully install the function notify handler
for other device objects under the given brigde.

To address this issue make register_slot() return success after
a new function has been added, even if the addition of the notify
handler for it has failed.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Hotplug context objects for bridges and functions

When either a new hotplug bridge or a new hotplug function is added
by the ACPI-based PCI hotplug (ACPIPHP) code, attach a context object
to its ACPI handle to store hotplug-related information in it.  To
start with, put the handle's bridge and function pointers into that
object.  Count references to the context objects and drop them when
they are not needed any more.

First of all, this makes it possible to find out if the given bridge
has been registered as a function already in a much more
straightforward way and acpiphp_bridge_handle_to_function() can be
dropped (Yay!).

This also will allow some more simplifications to be made going
forward.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Unified notify handler for hotplug events

Using the hotplug context objects introduced previously rework the
ACPI-based PCI hotplug (ACPIPHP) core code so that all notifications
for ACPI device objects corresponding to the hotplug PCI devices are
handled by one function, handle_hotplug_event(), which recognizes
whether it has to handle a bridge or a function.

In addition to code size reduction it allows some ugly pieces of code
where notify handlers have to be uninstalled and installed again to
go away.  Moreover, it fixes a theoretically possible race between
handle_hotplug_event() and free_bridge() tearing down data structures
for the same handle.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Rework acpiphp_handle_to_bridge()

Using the hotplug context objects introduced previously rework the
ACPI-based PCI hotplug (ACPIPHP) core code to get to acpiphp_bridge
objects associated with hotplug bridges from those context objects
rather than from the global list of hotplug bridges.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Pass hotplug context objects to event handlers

Modify handle_hotplug_event() to pass the entire context object
(instead of its fields individually) to work functions started by it.

This change makes the subsequent consolidation of the event handling
work functions a bit more straightforward.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Merge hotplug event handling functions

There are separate handling event functions for hotplug bridges and
for hotplug functions, but they may be combined into one common
hotplug event handling function which simplifies the code slightly.

That also allows a theoretical bug to be dealt with which in
principle may occur if a hotplug bridge is on a dock station, because
in that case the bridge-specific notification should be used instead
of the function-specific one, but the dock station always uses the
latter.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Drop func field from struct acpiphp_bridge

Since the func pointer in struct acpiphp_context can always be used
instead of the func pointer in struct acpiphp_bridge, drop the
latter.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Refactor slot allocation code in register_slot()

To make the code in register_slot() a bit easier to follow, change
the way the slot allocation part is organized.  Drop one local
variable that's not used any more after that modification.

This code change should not lead to any changes in behavior.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Register all devices under the given bridge

Rework register_slot() to create a struct acpiphp_func object for
every function it is called for and to create acpiphp slots for all
of them.  Although acpiphp_register_hotplug_slot() is only called for
the slots whose functions are identified as "ejectable", so that user
space can manipulate them, the ACPIPHP notify handler,
handle_hotplug_event(), is now installed for all of the registered
functions (that aren't dock stations) and hotplug events may be
handled for all of them.

As a result, essentially, all PCI bridges represented by objects in
the ACPI namespace are now going to be "hotplug" bridges and that may
affect resources allocation in general, although it shouldn't lead to
problems.

This allows the code to be simplified substantially and addresses
the problem where bus check or device check notifications for some
PCI bridges or devices are not handled, because those devices are
not recognized as "ejectable" or there appear to be no "ejectable"
devices under those bridges.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Drop sun field from struct acpiphp_slot

If the slot unique number is passed as an additional argument to
acpiphp_register_hotplug_slot(), the slot field in struct
acpiphp_slot is not necessary and may be dropped, so make that
happen.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Drop flags field from struct acpiphp_bridge

The only bridge flag used by the ACPI-based PCI hotplug (ACPIPHP)
code is BRIDGE_HAS_EJ0, but it is only used by the event handling
function hotplug_event() and if that flag is set, the corresponding
function flag FUNC_HAS_EJ0 is set as well, so that bridge flag is
redundant.

For this reason, drop BRIDGE_HAS_EJ0 and all code referring to it
and since it is the only bridge flag defined, drop the flags field
from struct acpiphp_bridge entirely.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Embed function struct into struct acpiphp_context

Since there has to be a struct acpiphp_func object for every struct
acpiphp_context created by register_slot(), the struct acpiphp_func
one can be embedded into the struct acpiphp_context one, which allows
some code simplifications to be made.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Drop handle field from struct acpiphp_func

The ACPI handle stored in struct acpiphp_func is also stored in the
struct acpiphp_context object containing it and it is trivial to get
from a struct acpiphp_func pointer to the handle field of the outer
struct acpiphp_context.

Hence, the handle field of struct acpiphp_func is redundant, so drop
it and provide a helper function, func_to_handle(), allowing it
users to get the ACPI handle for the given struct acpiphp_func
pointer.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Drop handle field from struct acpiphp_bridge

The handle field in struct acpiphp_bridge is only used by
acpiphp_enumerate_slots(), but in that function the local handle
variable can be used instead, so make that happen and drop handle
from struct acpiphp_bridge.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Store parent in functions and bus in slots

To avoid chasing more pointers than necessary in some situations,
move the bridge pointer from struct acpiphp_slot to struct
acpiphp_func (and call it 'parent') and add a bus pointer to
struct acpiphp_slot.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / hotplug / PCI: Rework namespace scanning and trimming routines

The acpiphp_bus_trim() and acpiphp_bus_add() functions need not
return error codes that are never checked, so redefine them and
simplify them a bit.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>