Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 15 11月, 2011 1 次提交
  3. 12 11月, 2011 2 次提交
  5. 08 11月, 2011 1 次提交
  7. 01 11月, 2011 3 次提交
  9. 15 10月, 2011 1 次提交
    • P
      PCI hotplug: acpiphp: Prevent deadlock on PCI-to-PCI bridge remove · 6af8bef1
      由 Prarit Bhargava 提交于 
      I originally submitted a patch to workaround this by pushing all Ejection
Requests and Device Checks onto the kacpi_hotplug queue.

http://marc.info/?l=linux-acpi&m=131678270930105&w=2

The patch is still insufficient in that Bus Checks also need to be added.

Rather than add all events, including non-PCI-hotplug events, to the
hotplug queue, mjg suggested that a better approach would be to modify
the acpiphp driver so only acpiphp events would be added to the
kacpi_hotplug queue.

It's a longer patch, but at least we maintain the benefit of having separate
queues in ACPI.  This, of course, is still only a workaround the problem.
As Bjorn and mjg pointed out, we have to refactor a lot of this code to do
the right thing but at this point it is a better to have this code working.

The acpi core places all events on the kacpi_notify queue.  When the acpiphp
driver is loaded and a PCI card with a PCI-to-PCI bridge is removed the
following call sequence occurs:

cleanup_p2p_bridge()
	    -> cleanup_bridge()
		    -> acpi_remove_notify_handler()
			    -> acpi_os_wait_events_complete()
				    -> flush_workqueue(kacpi_notify_wq)

which is the queue we are currently executing on and the process will hang.

Move all hotplug acpiphp events onto the kacpi_hotplug workqueue.  In
handle_hotplug_event_bridge() and handle_hotplug_event_func() we can simply
push the rest of the work onto the kacpi_hotplug queue and then avoid the
deadlock.
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Cc: mjg@redhat.com
Cc: bhelgaas@google.com
Cc: linux-acpi@vger.kernel.org
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6af8bef1
  11. 10 9月, 2011 1 次提交
  13. 02 8月, 2011 1 次提交
    • J
      PCI: Set PCI-E Max Payload Size on fabric · b03e7495
      由 Jon Mason 提交于 
      On a given PCI-E fabric, each device, bridge, and root port can have a
different PCI-E maximum payload size.  There is a sizable performance
boost for having the largest possible maximum payload size on each PCI-E
device.  However, if improperly configured, fatal bus errors can occur.
Thus, it is important to ensure that PCI-E payloads sends by a device
are never larger than the MPS setting of all devices on the way to the
destination.

This can be achieved two ways:

- A conservative approach is to use the smallest common denominator of
  the entire tree below a root complex for every device on that fabric.

This means for example that having a 128 bytes MPS USB controller on one
leg of a switch will dramatically reduce performances of a video card or
10GE adapter on another leg of that same switch.

It also means that any hierarchy supporting hotplug slots (including
expresscard or thunderbolt I suppose, dbl check that) will have to be
entirely clamped to 128 bytes since we cannot predict what will be
plugged into those slots, and we cannot change the MPS on a "live"
system.

- A more optimal way is possible, if it falls within a couple of
  constraints:
* The top-level host bridge will never generate packets larger than the
  smallest TLP (or if it can be controlled independently from its MPS at
  least)
* The device will never generate packets larger than MPS (which can be
  configured via MRRS)
* No support of direct PCI-E <-> PCI-E transfers between devices without
  some additional code to specifically deal with that case

Then we can use an approach that basically ignores downstream requests
and focuses exclusively on upstream requests. In that case, all we need
to care about is that a device MPS is no larger than its parent MPS,
which allows us to keep all switches/bridges to the max MPS supported by
their parent and eventually the PHB.

In this case, your USB controller would no longer "starve" your 10GE
Ethernet and your hotplug slots won't affect your global MPS.
Additionally, the hotplugged devices themselves can be configured to a
larger MPS up to the value configured in the hotplug bridge.

To choose between the two available options, two PCI kernel boot args
have been added to the PCI calls.  "pcie_bus_safe" will provide the
former behavior, while "pcie_bus_perf" will perform the latter behavior.
By default, the latter behavior is used.

NOTE: due to the location of the enablement, each arch will need to add
calls to this function.  This patch only enables x86.

This patch includes a number of changes recommended by Benjamin
Herrenschmidt.

Tested-by: Jordan_Hargrave@dell.com
Signed-off-by: NJon Mason <mason@myri.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b03e7495
  15. 27 7月, 2011 1 次提交
  17. 23 7月, 2011 1 次提交
  19. 22 7月, 2011 3 次提交
  21. 17 7月, 2011 1 次提交
  23. 10 6月, 2011 1 次提交
  25. 08 6月, 2011 1 次提交
    • B
      pci/of: Match PCI devices to OF nodes dynamically · 98d9f30c
      由 Benjamin Herrenschmidt 提交于 
      powerpc has two different ways of matching PCI devices to their
corresponding OF node (if any) for historical reasons. The ppc64 one
does a scan looking for matching bus/dev/fn, while the ppc32 one does a
scan looking only for matching dev/fn on each level in order to be
agnostic to busses being renumbered (which Linux does on some
platforms).

This removes both and instead moves the matching code to the PCI core
itself. It's the most logical place to do it: when a pci_dev is created,
we know the parent and thus can do a single level scan for the matching
device_node (if any).

The benefit is that all archs now get the matching for free. There's one
hook the arch might want to provide to match a PHB bus to its device
node. A default weak implementation is provided that looks for the
parent device device node, but it's not entirely reliable on powerpc for
various reasons so powerpc provides its own.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NMichal Simek <monstr@monstr.eu>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      98d9f30c
  27. 12 5月, 2011 1 次提交
  29. 11 5月, 2011 1 次提交
  31. 31 3月, 2011 1 次提交
  33. 05 3月, 2011 1 次提交
    • S
      PCI hotplug: acpiphp: set current_state to D0 in register_slot · 47e9037a
      由 Stefano Stabellini 提交于 
      If a device doesn't support power management (pm_cap == 0) but it is
acpi_pci_power_manageable() because there is a _PS0 method declared for
it and _EJ0 is also declared for the slot then nobody is going to set
current_state = PCI_D0 for this device.  This is what I think it is
happening:

pci_enable_device
    |
__pci_enable_device_flags
/* here we do not set current_state because !pm_cap */
    |
do_pci_enable_device
    |
pci_set_power_state
    |
__pci_start_power_transition
    |
pci_platform_power_transition
/* platform_pci_power_manageable() calls acpi_pci_power_manageable that
 * returns true */
    |
platform_pci_set_power_state
/* acpi_pci_set_power_state gets called and does nothing because the
 * acpi device has _EJ0, see the comment "If the ACPI device has _EJ0,
 * ignore the device" */

at this point if we refer to the commit message that introduced the
comment above (10b3dcae), it is up to
the hotplug driver to set the state to D0.
However AFAICT the pci hotplug driver never does, in fact
drivers/pci/hotplug/acpiphp_glue.c:register_slot sets the slot flags to
(SLOT_ENABLED | SLOT_POWEREDON) but it does not set the pci device
current state to PCI_D0.

So my proposed fix is also to set current_state = PCI_D0 in
register_slot.
Comments are very welcome.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      47e9037a
  35. 11 1月, 2011 1 次提交
  37. 24 12月, 2010 1 次提交
  39. 12 11月, 2010 1 次提交
    • S
      PCI hotplug: ibmphp: Add check to prevent reading beyond mapped area · ac3abf2c
      由 Steven Rostedt 提交于 
      While testing various randconfigs with ktest.pl, I hit the following panic:

BUG: unable to handle kernel paging request at f7e54b03
IP: [<c0d63409>] ibmphp_access_ebda+0x101/0x19bb

Adding printks, I found that the loop that reads the ebda blocks
can move out of the mapped section.

ibmphp_access_ebda: start=f7e44c00 size=5120 end=f7e46000
ibmphp_access_ebda: io_mem=f7e44d80 offset=384
ibmphp_access_ebda: io_mem=f7e54b03 offset=65283

The start of the iomap was at f7e44c00 and had a size of 5120,
making the end f7e46000. We start with an offset of 0x180 or
384, giving the first read at 0xf7e44d80. Reading that location
yields 65283, which is much bigger than the 5120 that was allocated
and makes the next read at f7e54b03 which is outside the mapped area.

Perhaps this is a bug in the driver, or buggy hardware, but this patch
is more about not crashing my box on start up and just giving a warning
if it detects this error.

This patch at least lets my box boot with just a warning.

Cc: Chandru Siddalingappa <chandru@linux.vnet.ibm.com>
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      ac3abf2c
  41. 18 10月, 2010 2 次提交
    • T
      shpchp: update workqueue usage · e24dcbef
      由 Tejun Heo 提交于 
      * Rename shpchp_wq to shpchp_ordered_wq and add non-ordered shpchp_wq
  which is used instead of the system workqueue.  This is to remove
  the use of flush_scheduled_work() which is deprecated and scheduled
  for removal.

* With cmwq in place, there's no point in creating workqueues lazily.
  Create both shpchp_wq and shpchp_ordered_wq upfront.

* Include workqueue.h from shpchp.h.
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      e24dcbef
    • T
      pciehp: update workqueue usage · a827ea30
      由 Tejun Heo 提交于 
      * Rename pciehp_wq to pciehp_ordered_wq and add non-ordered pciehp_wq
  which is used instead of the system workqueue.  This is to remove
  the use of flush_scheduled_work() which is deprecated and scheduled
  for removal.

* With cmwq in place, there's no point in creating workqueues lazily.
  Create both pciehp_wq and pciehp_ordered_wq upfront.

* Include workqueue.h from pciehp.h.
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      a827ea30
  43. 16 10月, 2010 1 次提交
  45. 05 10月, 2010 1 次提交
    • A
      drivers: autoconvert trivial BKL users to private mutex · 613655fa
      由 Arnd Bergmann 提交于 
      All these files use the big kernel lock in a trivial
way to serialize their private file operations,
typically resulting from an earlier semi-automatic
pushdown from VFS.

None of these drivers appears to want to lock against
other code, and they all use the BKL as the top-level
lock in their file operations, meaning that there
is no lock-order inversion problem.

Consequently, we can remove the BKL completely,
replacing it with a per-file mutex in every case.
Using a scripted approach means we can avoid
typos.

These drivers do not seem to be under active
maintainance from my brief investigation. Apologies
to those maintainers that I have missed.

file=$1
name=$2
if grep -q lock_kernel ${file} ; then
    if grep -q 'include.*linux.mutex.h' ${file} ; then
            sed -i '/include.*<linux\/smp_lock.h>/d' ${file}
    else
            sed -i 's/include.*<linux\/smp_lock.h>.*$/include <linux\/mutex.h>/g' ${file}
    fi
    sed -i ${file} \
        -e "/^#include.*linux.mutex.h/,$ {
                1,/^\(static\|int\|long\)/ {
                     /^\(static\|int\|long\)/istatic DEFINE_MUTEX(${name}_mutex);

} }"  \
    -e "s/\(un\)*lock_kernel\>[ ]*()/mutex_\1lock(\&${name}_mutex)/g" \
    -e '/[      ]*cycle_kernel_lock();/d'
else
    sed -i -e '/include.*\<smp_lock.h\>/d' ${file}  \
                -e '/cycle_kernel_lock()/d'
fi
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      613655fa
  47. 26 8月, 2010 1 次提交
  49. 25 8月, 2010 2 次提交
    • R
      PCI: PCIe: Ask BIOS for control of all native services at once · 28eb5f27
      由 Rafael J. Wysocki 提交于 
      After commit 852972ac (ACPI: Disable
ASPM if the platform won't provide _OSC control for PCIe) control of
the PCIe Capability Structure is unconditionally requested by
acpi_pci_root_add(), which in principle may cause problems to
happen in two ways.  First, the BIOS may refuse to give control of
the PCIe Capability Structure if it is not asked for any of the
_OSC features depending on it at the same time.  Second, the BIOS may
assume that control of the _OSC features depending on the PCIe
Capability Structure will be requested in the future and may behave
incorrectly if that doesn't happen.  For this reason, control of
the PCIe Capability Structure should always be requested along with
control of any other _OSC features that may depend on it (ie. PCIe
native PME, PCIe native hot-plug, PCIe AER).

Rework the PCIe port driver so that (1) it checks which native PCIe
port services can be enabled, according to the BIOS, and (2) it
requests control of all these services simultaneously.  In
particular, this causes pcie_portdrv_probe() to fail if the BIOS
refuses to grant control of the PCIe Capability Structure, which
means that no native PCIe port services can be enabled for the PCIe
Root Complex the given port belongs to.  If that happens, ASPM is
disabled to avoid problems with mishandling it by the part of the
PCIe hierarchy for which control of the PCIe Capability Structure
has not been received.

Make it possible to override this behavior using 'pcie_ports=native'
(use the PCIe native services regardless of the BIOS response to the
control request), or 'pcie_ports=compat' (do not use the PCIe native
services at all).

Accordingly, rework the existing PCIe port service drivers so that
they don't request control of the services directly.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      28eb5f27
    • R
      ACPI/PCI: Negotiate _OSC control bits before requesting them · 75fb60f2
      由 Rafael J. Wysocki 提交于 
      It is possible that the BIOS will not grant control of all _OSC
features requested via acpi_pci_osc_control_set(), so it is
recommended to negotiate the final set of _OSC features with the
query flag set before calling _OSC to request control of these
features.

To implement it, rework acpi_pci_osc_control_set() so that the caller
can specify the mask of _OSC control bits to negotiate and the mask
of _OSC control bits that are absolutely necessary to it.  Then,
acpi_pci_osc_control_set() will run _OSC queries in a loop until
the mask of _OSC control bits returned by the BIOS is equal to the
mask passed to it.  Also, before running the _OSC request
acpi_pci_osc_control_set() will check if the caller's required
control bits are present in the final mask.

Using this mechanism we will be able to avoid situations in which the
BIOS doesn't grant control of certain _OSC features, because they
depend on some other _OSC features that have not been requested.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      75fb60f2
  51. 31 7月, 2010 4 次提交
  53. 12 6月, 2010 1 次提交
    • J
      PCI: hotplug/cpqphp, fix NULL dereference · a7ef7d1f
      由 Jiri Slaby 提交于 
      There are devices out there which are PCI Hot-plug controllers with
compaq PCI IDs, but are not bridges, hence have pdev->subordinate
NULL. But cpqphp expects the pointer to be non-NULL.

Add a check to the probe function to avoid oopses like:
BUG: unable to handle kernel NULL pointer dereference at 00000050
IP: [<f82e3c41>] cpqhpc_probe+0x951/0x1120 [cpqphp]
*pdpt = 0000000033779001 *pde = 0000000000000000
...

The device here was:
00:0b.0 PCI Hot-plug controller [0804]: Compaq Computer Corporation PCI Hotplug Controller [0e11:a0f7] (rev 11)
	Subsystem: Compaq Computer Corporation Device [0e11:a2f8]
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      a7ef7d1f
  55. 22 5月, 2010 2 次提交
  57. 19 5月, 2010 1 次提交