IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The second parameter of of_read_number() is not the index, but a size. As
it happens, in this case it may work just fine because of the conversion to
u32 and the favorable endianness on this architecture.
Fixes: 11be65472a427 ("PCI: mvebu: Adapt to the new device tree layout")
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Cc: stable@vger.kernel.org # v3.12+
Replace list_for_each() + pci_bus_b() with list_for_each_entry().
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
If we found device already exists during hot add device, we should leave
it, not turn the slot off.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Coverity reported that I forgot to clean up some allocated memory on the
error path in populate_msi_sysfs(), so this patch fixes that.
Thanks to Dave Jones for pointing out where the error was, I obviously
can't read code this morning...
Found by Coverity (CID 1163317).
Fixes: 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not kobjects")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Dave Jones <davej@redhat.com>
Coverity reported that I forgot to check the return value of kmalloc() when
creating the MSI attribute name, so fix that up and properly free it if
there is an error when allocating the msi_dev_attr variable.
Found by Coverity (CID 1163315 and 1163316).
Fixes: 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not kobjects")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
setup-bus.o is now included unconditionally as of commit 7dc303033425
("PCI: Always build setup-bus when PCI is enabled"). Remove it from the
per-arch list of object files.
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
This is a static checker fix and I can't test it, but from the context it
definitely looks like hexadecimal 0x20 was intended here instead of decimal
20.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Marvell SoCs place the SoC number into the PCIe endpoint device ID. The
SoC stepping is placed into the PCIe revision. The old plat-orion PCIe
driver allowed this information to be seen in user space with a simple
lspci command.
The new driver places a virtual PCI-PCI bridge on top of these endpoints.
It has its own hard coded PCI device ID. Thus it is no longer possible to
see what the SoC is using lspci.
When initializing the PCI-PCI bridge, set its device ID and revision from
the underlying endpoint, thus restoring this functionality. Debian would
like to use this in order to aid installing the correct DTB file.
Fixes: 45361a4fe4464 ("pci: PCIe driver for Marvell Armada 370/XP systems")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Cc: stable@vger.kernel.org # v3.11+
Marvell SoCs place the SoC number into the PCIe endpoint device ID. The
SoC stepping is placed into the PCIe revision. The old plat-orion PCIe
driver allowed this information to be seen in user space with a simple
lspci command.
The new driver places a virtual PCI-PCI bridge on top of these endpoints.
It has its own hard coded PCI device ID. Thus it is no longer possible to
see what the SoC is using lspci.
When initializing the PCI-PCI bridge, set its device ID and revision from
the underlying endpoint, thus restoring this functionality. Debian would
like to use this in order to aid installing the correct DTB file.
Fixes: 45361a4fe4464 ("pci: PCIe driver for Marvell Armada 370/XP systems")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Cc: stable@vger.kernel.org # v3.11+
The ACPI specification (ACPI 5.0A, Section 6.3.7) says:
_STA may return bit 0 clear (not present) with bit 3 set (device is
functional). This case is used to indicate a valid device for which
no device driver should be loaded (for example, a bridge device.)
Children of this device may be present and valid. OSPM should
continue enumeration below a device whose _STA returns this bit
combination.
Evidently, some BIOSes follow that and return 0x0A from _STA, which
causes problems to happen when they trigger bus check or device check
notifications for those devices too. Namely, ACPIPHP thinks that they
are gone and may drop them, for example, if such a notification is
triggered during a resume from system suspend.
To fix that, modify ACPICA to regard devies as present and
functioning if _STA returns both the ACPI_STA_DEVICE_ENABLED
and ACPI_STA_DEVICE_FUNCTIONING bits set for them.
Reported-and-tested-by: Peter Wu <lekensteyn@gmail.com>
Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
[rjw: Subject and changelog, minor code modifications]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Today it is there is no protection around pciehp_enable_slot() and
pciehp_disable_slot() to ensure that they complete before another
hot-plug operation can be done on that particular slot.
This patch introduces the slot->hotplug_lock to ensure that any hotplug
operations (add / remove) complete before another hotplug event can begin
processing on that particular slot.
Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Today, this is how all the hotplug and unplug events work:
Hotplug / Removal needs to be done
=> Set slot->state (protected by slot->lock) to either
POWERON_STATE (for enabling) or POWEROFF_STATE (for disabling).
=> Submit the work item for pciehp_power_thread() to slot->wq.
Problem:
There is a problem if the hotplug events can happen fast enough that
they do not give SW enough time to add or remove the new devices.
=> Assume: Event for unplug comes (e.g. surprise removal). But
before the pciehp_power_thread() work item was executed, the
card was replaced by another card, causing surprise hotplug event.
=> What goes wrong:
=> The hot-removal event sets slot->state to POWEROFF_STATE, and
schedules the pciehp_power_thread().
=> The hot-add event sets slot->state to POWERON_STATE, and
schedules the pciehp_power_thread().
=> Now the pciehp_power_thread() is scheduled twice, and on both
occasions it will find POWERON_STATE and will try to add the
devices on the slot, and will fail complaining that the devices
already exist.
=> Why this is a problem: If the device was replaced between the hot
removal and hot-add, then we should unload the old driver and
reload the new one. This does not happen today. The kernel or the
driver is not even aware that the device was replaced.
The problem is that the pciehp_power_thread() only looks at the
slot->state which would only contain the *latest* state - not
the actual event (add / remove) that was the intent of the IRQ
handler who submitted the work.
What this patch does:
=> Hotplug events pass on an actual request (for addition or removal)
to pciehp_power_thread() which is local to that work item
submission.
=> pciehp_power_thread() does not need to look at slote->state and
hence no locks needed in that.
=> Essentially this results in all the hotplug and unplug events
"replayed" by pciehp_power_thread().
Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Disable the link notification (in addition to presence detect
notifications) across the slot reset since the reset could flap the link,
and we don't want to treat it as hot unplug followed by a hotplug.
Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
It does not make much sense to refuse to disable a slot if an adapter is
not present or the latch is open. If an adapter is not present, it provides
an even better reason to disable the device slot.
This is specially a problem for link state hot-plug, because some ports use
in band mechanism for presence detection. Thus when link goes down,
presence detect also goes down. We _want_ that the removal should take
place in such case.
Thus remove the checks for adapter and latch in pciehp_disable_slot()
Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
We need future link up events for hot-add, thus don't disable the link
permanently during device removal. Also, remove the static functions that
are now left unused.
This reverts part of 2debd9289997 ("PCI: pciehp: Disable/enable link during
slot power off/on"). This was discussed at the URL below, where it was
revealed that it was done for a bug in a PCIe repeater chip on that
particular platform.
Link: https://lkml.kernel.org/r/CAErSpo72KZ-a2OSQLWoK71GCgwBt676XZdGt4tEYm-6UYnLmPw@mail.gmail.com
Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Enable the Link state notifications unconditionally. Enable the
presence detection notification only if attention button is absent.
This was discussed at this thread:
https://lkml.kernel.org/r/529E5C0E.80903@gmail.com
Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
When assigning a new bus number in pci_scan_bridge we check whether
max+1 is free by calling pci_find_bus. If it does already exist then we
assume that we are rescanning and that this is the right bus to scan.
This is fragile. If max+1 lies outside of bus->busn_res.end then we will
rescan some random bus from somewhere else in the hierachy. This patch
checks for this case and prints a warning.
[bhelgaas: add parent/child bus number info to dev_warn()]
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
pci_scan_child_bus can (potentially) return a bus number higher than the
subordinate value of the child bus. Possible reasons are that bus numbers
are reserved for SR-IOV or for CardBus (SR-IOV is done without checks and
the CardBus checks are sketchy at best).
We clamp the returned value to the actual subordinate value and print a
warning if too many bus numbers are reserved.
[bhelgaas: whitespace]
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The function has no effect.
If pcibios_assign_all_busses() is not set then the function does nothing.
If it is set then in pci_scan_bridge we are always in the branch where
we assign the bus numbers ourselves and the subordinate values of all
parent busses will be set to 0xff since that is what they inherited from
their parent bus and ultimately from the root bus.
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Many of the currently available Intel PCH-based root ports do not provide
PCIe ACS capabilities. Without this, we must assume that peer-to-peer
traffic between multifunction root ports and between devices behind root
ports is possible. This lack of isolation is exposed by grouping the
devices together in the same IOMMU group. If we want to expose these
devices to userspace, vfio uses IOMMU groups as the unit of ownership, thus
making it very difficult to assign individual devices to separate users.
The good news is that the chipset does provide ACS-like isolation
capabilities, but we do need to verify and enable those capabilities if the
BIOS has not done so. This patch implements the device specific enabling
and testing of equivalent ACS function for these devices.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Don Dugger <donald.d.dugger@intel.com>
Some devices support PCI ACS-like features, but don't report it using the
standard PCIe capabilities. We already provide hooks for device-specific
testing of ACS, but not for device-specific enabling of ACS. This provides
that setup hook.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
A lot of systems do not have the fancy buttons and LEDs, and instead
want to rely only on the Link state change events to drive the hotplug
and removal state machinery.
(http://www.spinics.net/lists/hotplug/msg05802.html)
This patch adds support for that functionality. Here are the details
about the patch itself:
* Define and use interrupt events for linkup / linkdown.
* Make the pcie_isr() also look at link events, and direct control to
corresponding (new) link state change handler function.
* Introduce the functions to handle link-up and link-down events and
queue the add / removal work in the slot->wq to be processed by
pciehp_power_thread()
As a side note, this patch also fixes the bug
https://bugzilla.kernel.org/show_bug.cgi?id=65521 "pciehp ignores Data Link
Layer State Changed bit."
Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
check_link_active() functionality needs to be used by subsequent patches
(that introduce link state change based hotplug). Thus make the function
non-static, and rename it to pciehp_check_link_active() so as to be
consistent with other non-static functions.
Signed-off-by: Rajat Jain <rajatxjain@gmail.com>
Signed-off-by: Rajat Jain <rajatjain@juniper.net>
Signed-off-by: Guenter Roeck <groeck@juniper.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
da9846ae1518 ("kernfs: make kernfs_deactivate() honor KERNFS_LOCKDEP
flag") in driver-core-linus conflicts with kernfs_drain() updates in
driver-core-next. The former just adds the missing KERNFS_LOCKDEP
checks which are already handled by kernfs_lockdep() checks in
driver-core-next. The conflict can be resolved by taking code from
driver-core-next.
Conflicts:
fs/kernfs/dir.c
Right now we use 0xff for busn_res.end when probing and later reduce it to
the value that is actually used. This does not work if a parent bridge has
already a lower subordinate value. For example during hotplug of a new
bridge below an already-configured bridge the following message is printed
from pci_bus_insert_busn_res():
pci_bus 0000:06: busn_res: can not insert [bus 06-ff] under [bus 05-9b] (conflicts with (null) [bus 05-9b])
This patch clamps the bus range to that of the parent and also ensures that
we do not exceed the parents range when assigning the final subordinate
value.
We also check that busses configured by the firmware fit into their parents
bounds.
[bhelgaas: reword dev_warn() and fix printk format warning]
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
If a conflict happens during insert_resource_conflict() and all conflicts
fit within the newly inserted resource then they will become children of
the new resource. This is almost certainly not what we want for bus
numbers.
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Right now the CardBus code in pci_scan_bridge() is executed during both
passes. Since we always allocate the bus number ourselves it makes sense
to put it into the second pass.
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Initially when we encountered a bus that was already present we skipped
it. Since 74710ded8e16 'PCI: always scan child buses' we continue
scanning in order to allow user triggered rescans of already existing
busses.
The old comment suggested that the reason for continuing the scan is a
bug in the i450NX chipset. This is not the case.
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
This patch fixes two small issues:
- If pci_add_new_bus() fails, max must not be incremented. Otherwise
an incorrect value is returned from pci_scan_bridge().
- If the bus is already present, max must be incremented. I think
that this case should only be hit if we trigger a manual rescan of a
CardBus bridge.
Signed-off-by: Andreas Noever <andreas.noever@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Since acpi_device_hotplug() assumes that ACPI handles of device
objects passed to it will not become invalid while acpi_scan_lock
is being held, make acpiphp_disable_slot() acquire acpi_scan_lock,
because it generally causes _EJ0 to be executed for one of the
devices in the slot and that may cause its ACPI handle to become
invalid.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
driver-core now supports synchrnous self-deletion of attributes and
the asynchrnous removal mechanism is scheduled for removal. Use it
instead of device_schedule_callback(). This makes "remove" behave
synchronously.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since the only existing caller of acpiphp_check_host_bridge(),
which is acpi_pci_root_scan_dependent(), already has a struct
acpi_device pointer needed to obtain the ACPIPHP context, it
doesn't make sense to execute acpi_bus_get_device() on its
handle in acpiphp_handle_to_bridge() just in order to get that
pointer back.
For this reason, modify acpiphp_check_host_bridge() to take
a struct acpi_device pointer as its argument and rearrange the
code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Since acpi_bus_notify() is executed on all notifications for all
devices anyway, make it execute acpi_device_hotplug() for all
hotplug events instead of installing notify handlers pointing to
the same function for all hotplug devices.
This change reduces both the size and complexity of ACPI-based device
hotplug code. Moreover, since acpi_device_hotplug() only does
significant things for devices that have either an ACPI scan handler,
or a hotplug context with .eject() defined, and those devices
had notify handlers pointing to acpi_hotplug_notify_cb() installed
before anyway, this modification shouldn't change functionality.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since acpi_hotplug_notify_cb() does not use its data argument any
more, the second argument of acpi_install_hotplug_notify_handler()
can be dropped, so do that and update its callers accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI-based PCI hotplug (ACPIPHP) code currently attaches its
hotplug context objects directly to ACPI namespace nodes representing
hotplug devices. However, after recent changes causing struct
acpi_device to be created for every namespace node representing a
device (regardless of its status), that is not necessary any more.
Moreover, it's vulnerable to the theoretical issue that the ACPI
handle passed in the context between handle_hotplug_event() and
hotplug_event_work() may become invalid in the meantime (as a
result of a concurrent table unload).
In principle, this issue might be addressed by adding a non-empty
release handler for ACPIPHP hotplug context objects analogous to
acpi_scan_drop_device(), but that would duplicate the code in that
function and in acpi_device_del_work_fn(). For this reason, it's
better to modify ACPIPHP to attach its device hotplug contexts to
struct device objects representing hotplug devices and make it
use acpi_hotplug_notify_cb() as its notify handler. At the same
time, acpi_device_hotplug() can be modified to dispatch the new
.hp.event() callback pointing to acpiphp_hotplug_event() from ACPI
device objects associated with PCI devices or use the generic
ACPI device hotplug code for device objects with matching scan
handlers.
This allows the existing code duplication between ACPIPHP and the
ACPI core to be reduced too and makes further ACPI-based device
hotplug consolidation possible.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Subsequent changes will require the ACPI core to acquire the lock
protecting the ACPIPHP hotplug contexts, so move the definition of
the lock to the core and change its name to be more generic.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Since hotplug_event() can get the ACPI handle needed for debug
printouts from its context argument, there's no need to pass the
handle to it. Moreover, the second argument's type may be changed
to (struct acpiphp_context *), because that's what is always passed
to hotplug_event() as the second argument anyway.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Make hotplug_event() use acpi_handle_debug() instead of an open-coded
debug message printing and clean up the messages printed by it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
A few lines of code can be cut from hotplug_event() by defining
and initializing the slot variable at the top of the function,
so do that.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
After recent PCI core changes related to the rescan/remove locking,
the code sections under crit_sect mutexes from ACPIPHP slot objects
are always executed under the general PCI rescan/remove lock.
For this reason, the crit_sect mutexes are simply redundant, so drop
them.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
acpiphp_bus_add() is only called from one place, so move the code out
of it into that place and drop it. Also make that code use
func_to_acpi_device() to get the struct acpi_device pointer it needs
instead of calling acpi_bus_get_device() which may be costly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
After recent modifications of the ACPI core making it create a struct
acpi_device object for every namespace node representing a device
regardless of the current status of that device the ACPIPHP code
can store a struct acpi_device pointer instead of an ACPI handle
in struct acpiphp_context. This immediately makes it possible to
avoid making potentially costly calls to acpi_bus_get_device() in
two places and allows some more simplifications to be made going
forward.
The reason why that is correct is because ACPIPHP only installs
hotify handlers for namespace nodes that exist when
acpiphp_enumerate_slots() is called for their parent bridge.
That only happens if the parent bridge has an ACPI companion
associated with it, which means that the ACPI namespace scope
in question has been scanned already at that point. That, in
turn, means that struct acpi_device objects have been created
for all namespace nodes in that scope and pointers to those
objects can be stored directly instead of their ACPI handles.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
If a struct acpi_device pointer is passed to acpiphp_no_hotplug()
instead of an ACPI handle, the function won't need to call
acpi_bus_get_device(), which may be costly, any more. Then,
trim_stale_devices() can call acpiphp_no_hotplug() passing
the struct acpi_device object it already has directly to that
function.
Make those changes and update slot_no_hotplug() accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
If trim_stale_devices() calls acpi_bus_trim() directly, we can
save a potentially costly acpi_bus_get_device() invocation. After
making that change acpiphp_bus_trim() would only be called from one
place, so move the code from it to that place and drop it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The err label in register_slot() is only jumped to from one place,
so move the code under the label to that place and drop the label.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Add proper kerneldoc comments describing acpiphp_enumerate_slots()
and acpiphp_remove_slots().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
After recent PCI core changes related to the rescan/remove locking,
the ACPIPHP's disable_slot() function is only called under the
general PCI rescan/remove lock, so it doesn't have to use
dev_in_slot() any more to avoid race conditions. Make it simply
walk the devices on the bus and drop the ones in the slot being
disabled and drop dev_in_slot() which has no more users.
Moreover, to avoid problems described in the changelog of commit
29ed1f29b68a (PCI: pciehp: Fix null pointer deref when hot-removing
SR-IOV device), make disable_slot() carry out the list walk in
reverse order.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
list_for_each_entry() handles empty lists just fine, so there's no need to
check whether the list is empty first.
No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
