- 24 9月, 2014 1 次提交
-
-
由 Yinghai Lu 提交于
When we warned about a timeout on a hotplug command, we previously printed the time between calls to pcie_write_cmd(), without accounting for any time spent actually waiting. Consider this sequence: pcie_write_cmd write SLTCTL cmd_started = jiffies # T1 pcie_write_cmd pcie_wait_cmd now = jiffies # T2 wait_event_timeout # we may wait here if (timeout) ctrl_info("Timeout on command issued %u msec ago", jiffies_to_msecs(now - cmd_started)) We previously printed (T2 - T1), but that doesn't include the time spent in wait_event_timeout(). Fix this by using the current jiffies value, not the one cached before calling wait_event_timeout(). [bhelgaas: changelog, use current jiffies instead of adding timeout] Fixes: 40b96083 ("PCI: pciehp: Compute timeout from hotplug command start time") Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 17 9月, 2014 1 次提交
-
-
由 Andreas Noever 提交于
pciehp assumes that dev->subordinate, the struct pci_bus for a bridge's secondary bus, exists. But we do not create that bus if we run out of bus numbers during enumeration. This leads to a NULL dereference in init_slot() (and other places). Change pciehp_probe() to return -ENODEV when no secondary bus is present. Signed-off-by: NAndreas Noever <andreas.noever@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.2+
-
- 13 9月, 2014 16 次提交
-
-
由 Bjorn Helgaas 提交于
4283c70e ("PCI: pciehp: Make pcie_wait_cmd() self-contained") added a cache of the most recent command written to the Slot Control register. This register is only 16 bits wide, but the cache ("slot_ctrl") is 32 bits. Reduce slot_ctrl to a u16 so it matches the register size. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
There's not really a good way to determine whether firmware has already configured a device with _HPP/_HPX settings. On legacy systems, the BIOS has probably configured everything, but on UEFI systems it is not required to do so. Per the PCI Firmware Specification, rev 3.1, sec 3.5, if PCI_COMMAND_IO or PCI_COMMAND_MEMORY is set, we can assume firmware has set the corresponding BARs and maybe we can assume it has configured the rest of the device. And if a bridge has PCI_COMMAND_PARITY or PCI_COMMAND_SERR set, we can assume firmware has configured the bridge. But we can't tell much about devices without BARs. I think it should be safe to apply _HPP and _HPX settings anyway, even if firmware has already configured the device, so configure everything we find. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
Linux manages MPS and MRRS settings to keep them consistent across the PCIe fabric. BIOS doesn't participate in this Linux management, so ignore that part of any _HPX settings it supplies. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
We currently apply _HPP settings only to: - non-bridge devices, and - PCI-to-PCI bridges i.e., we do not apply them to PCI-to-ISA bridges and the like. It has been that way since _HPP support was added by 40abb96c ("pciehp: Fix programming hotplug parameters"), but I don't think there's any reason to exclude these other bridges. Apply _HPP settings to hot-added PCI devices of any type. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
Do not clear PCI_COMMAND_SERR or PCI_COMMAND_PARITY based on _HPP. The spec (ACPI rev 5.0, sec 6.2.7) says that when "Enable SERR" is set to 1, we should enable SERR in the command register. It says nothing about *disabling* SERR or PERR; in fact, the example in 6.2.7.1 says we should leave PERR alone unless "Enable PERR" is 1. For hot-added devices, this probably doesn't matter because they power up with these bits cleared. But in addition to hot-plugged devices, the spec allows the platform to use _HPP for "configuration of PCI devices not configured by the BIOS at system boot," and it may make a difference for devices present at boot. This change means that if BIOS enables SERR or PERR on a device, and it supplies _HPP or _HPX with the SERR or PERR bits *cleared*, we will now leave SERR or PERR reporting enabled on that device instead of disabling it as we previously did. See also 40abb96c ("pciehp: Fix programming hotplug parameters"), where this code was first added. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
The ACPI _HPP method was defined before PCIe existed, so its documentation only mentions PCI. The _HPX Type 0 setting record is essentially identical to _HPP, but the spec (ACPI rev 5.0, sec 6.2.8.1) says it should be applied to PCI, PCI-X, and PCIe devices, with settings being ignored if they are not applicable. Some platforms with both conventional PCI and PCIe devices provide only _HPP (not _HPX), so treat _HPP the same way as an _HPX Type 0 record and apply it to PCIe devices as well as PCI and PCI-X. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
All pci_configure_slot() uses have been removed, so remove the definition as well. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
We now configure each PCI device as it is enumerated, in pci_device_add(), so remove the configuration done in acpiphp. That configuration, in pci_configure_device(), does not include the MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep that here. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
We now configure each PCI device as it is enumerated, in pci_device_add(), so remove the configuration done in shpchp. That configuration, in pci_configure_device(), does not include the MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep that here. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
We now configure each PCI device as it is enumerated, in pci_device_add(), so remove the configuration done in pciehp. That configuration, in pci_configure_device(), does not include the MPS/MRRS configuration done by pcie_bus_configure_settings(), so keep that here. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
Some platforms can tell the OS how to configure PCI devices, e.g., how to set cache line size, error reporting enables, etc. ACPI defines _HPP and _HPX methods for this purpose. This configuration was previously done by some of the hotplug drivers using pci_configure_slot(). But not all hotplug drivers did this, and per the spec (ACPI rev 5.0, sec 6.2.7), we can also do it for "devices not configured by the BIOS at system boot." Move this configuration into the PCI core by adding pci_configure_device() and calling it from pci_device_add(), so we do this for all devices as we enumerate them. This is based on pci_configure_slot(), which is used by hotplug drivers. I omitted: - pcie_bus_configure_settings() because it configures MPS and MRRS, which requires global knowledge of the fabric and must be done later, and - configuration of subordinate devices; that will happen when we call pci_device_add() for those devices. Because pci_configure_slot() was only done by hotplug drivers, this initial version of pci_configure_device() only configures hot-added devices, ignoring anything added during boot. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
Move pci_configure_slot() and related functions from drivers/pci/hotplug/pcihp_slot to drivers/pci/probe.c. This is to prepare for doing device configuration during the normal enumeration process instead of just after hot-add. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Move code around to put all the ACPI power management stuff together and all the pieces related to ACPI methods (_CBA, _HPP, _HPX) together. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Whitespace fixes only; no functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Move pci_get_hp_params() and related functions from drivers/pci/hotplug/acpi_pcihp.c to drivers/pci/pci-acpi.c. Previously, pci_get_hp_params() was used only by hotplug drivers. But future changes will move this into the normal device enumeration process, so it will be used even when CONFIG_HOTPLUG_PCI is not set. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
We configure cache line size and other settings of hot-added devices, e.g., based on ACPI _HPP or _HPX methods. Previously we skipped this for display devices, but ACPI rev 5.0, sec 6.2.7 and 6.2.8 have no requirement to skip them. Remove the check so we configure display devices the same way we configure other devices. See also ac81860e ("PCI: hotplug: pciehp: Removed check for hotplug of display devices"). Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
- 12 9月, 2014 1 次提交
-
-
由 Bjorn Helgaas 提交于
We print way too many messages like this: pci 0000:00:00.0: no hotplug settings from platform pci 0000:00:00.0: using default PCI settings This usually happens when the platform doesn't supply an ACPI _HPP method, but the method is optional, so there's no point in warning about it. Not only are the messages useless, but we call pci_configure_slot() far too many times, so they're repeated many times. I'll fix the overuse of pci_configure_slot() too, but that will wait until the next merge window. For now, just remove both log messages. Link: https://bugzilla.kernel.org/show_bug.cgi?id=84391Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
- 25 8月, 2014 1 次提交
-
-
由 Pawel Moll 提交于
A message warning a user about wrong vc value was printing out port instead. Reported-by: NDrew Richardson <drew.richardson@arm.com> Signed-off-by: NPawel Moll <pawel.moll@arm.com> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
- 23 8月, 2014 5 次提交
-
-
由 Rasmus Villemoes 提交于
Test for definedness of the macro which is actually defined (the change is hard to see: it is s/SSS/SSA/). Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Rasmus Villemoes 提交于
Nothing defines _ASM_GENERIC_INT_L64_H, it is a weird way to check for 64 bit longs, and u64 should be printed using %llx anyway. Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Anton Blanchard 提交于
Hidden away in the last 8 bytes of the buffer_list page is a solitary statistic. It needs to be byte swapped or else ethtool -S will produce numbers that terrify the user. Since we do this in multiple places, create a helper function with a comment explaining what is going on. Signed-off-by: NAnton Blanchard <anton@samba.org> Cc: stable@vger.kernel.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Iyappan Subramanian 提交于
A NULL pointer dereference is possible for the argument ring->buf_pool which is passed to xgene_enet_free_desc_ring(), as ring could be NULL. And now since NULL pointers are being checked for before the calls to xgene_enet_free_desc_ring(), might as well take advantage of them and not call the function if the argument would be NULL. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NIyappan Subramanian <isubramanian@apm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Nimrod Andy 提交于
The current kernel hang on i.MX6SX with rootfs mount from MMC. The root cause is that ptp uses a periodic timer to access enet register even if ipg clock is disabled. FEC ptp driver start one period timer to read 1588 counter register in the ptp init function that is called after FEC driver is probed. To save power, after FEC probe finish, FEC driver disable all clocks including ipg clock that is needed for register access. i.MX5x, i.MX6q/dl/sl FEC register access don't cause system hang when ipg clock is disabled, just return zero value. But for i.MX6sx SOC, it cause system hang. To avoid the issue, we need to check ptp clock status before ptp timer count access. Signed-off-by: NFugang Duan <B38611@freescale.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 22 8月, 2014 10 次提交
-
-
由 Alex Deucher 提交于
bug: https://bugs.freedesktop.org/show_bug.cgi?id=82912Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Guenter Roeck 提交于
spin_is_locked() always returns false for uniprocessor configurations in several architectures, so do not use WARN_ON with it. Use lockdep_assert_held() instead to also reduce overhead in non-debug kernels. Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Cc: <stable@vger.kernel.org> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Hariprasad Shenai 提交于
Description of problem: The NIC card is not reporting back to the driver the transmitted skbs, so they get stuck in the TX ring causing issues with reference counters in other kernel components. Developed a new Automatic Egress Queue Update firmware facility to slowly tick through Egress Queues and send back any outstanding CIDX Updates which are laying around. Based on original work by Casey Leedom <leedom@chelsio.com> Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Anish Bhatt 提交于
There is a possible race condition when we unregister the PCI Driver and then flush/destroy the global "workq". This could lead to situations where there are tasks on the Work Queue with references to now deleted adapter data structures. Instead, have per-adapter Work Queues which were instantiated and torn down in init_one() and remove_one(), respectively. v2: Remove unnecessary call to flush_workqueue() before destroy_workqueue() Signed-off-by: NAnish Bhatt <anish@chelsio.com> Signed-off-by: NCasey Leedom <leedom@chelsio.com> Acked-by: NNeil Horman <nhorman@tuxdriver.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Geert Uytterhoeven 提交于
Currently the sh-intc driver is compiled on all SuperH and non-multiplatform SH-Mobile platforms, while it's only used on a limited number of platforms: - SuperH: SH2(A), SH3(A), SH4(A)(L) (all but SH5) - ARM: sh7372, sh73a0 Drop the "default y" on SH_INTC, make all CPU platforms that use it select it, and protect all sub-options by "if SH_INTC" to fix this. Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Acked-by: NMagnus Damm <damm+renesas@opensource.se> Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
-
由 Yuval Mintz 提交于
Commit 91ebb929 ("bnx2x: Add support for Multi-Function UNDI") [which was later supposedly fixed by de682941 ("bnx2x: Fix UNDI driver unload")] introduced a bug in which in some [yet-to-be-determined] scenarios the alternative flushing mechanism which was to guarantee the Rx buffers are empty before resetting them during device probe will fail. If this happens, when device will be loaded once more a fatal attention will occur; Since this most likely happens in boot from SAN scenarios, the machine will fail to load. Notice this may occur not only in the 'Multi-Function' scenario but in the regular scenario as well, i.e., this introduced a regression in the driver's ability to perform boot from SAN. The patch reverts the mechanism and applies the old scheme to multi-function devices as well as to single-function devices. Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: NAriel Elior <Ariel.Elior@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Shahed Shaikh 提交于
Firmware binary file is in little endian. On big-endian architecture, while writing this binary FW file to adapters memory, writel() swaps the data resulting into corruption of FW image. So, swap the data before writing into adapters memory. Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Rajesh Borundia 提交于
Firmware dump template header is read from adapter using readl() which swaps the data. So, adjust structure element on the boundary of 32bit dword. Signed-off-by: NRajesh Borundia <rajesh.borundia@qlogic.com> Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jitendra Kalsaria 提交于
Application expects flash data in little endian, but driver reads/writes flash data using readl()/writel() APIs which swaps data on big endian machine. So, swap the data after reading from and before writing to flash memory. Signed-off-by: NJitendra Kalsaria <jitendra.kalsaria@qlogic.com> Signed-off-by: NShahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Vlad Yasevich 提交于
Currently, macvlan code restricts multicast and unicast filter setting only to passthru devices. As a result, if a guest using macvtap wants to receive multicast traffic, it has to set IFF_ALLMULTI or IFF_PROMISC. This patch makes it possible to use the fdb interface to add multicast addresses to the filter thus allowing a guest to receive only targeted multicast traffic. CC: John Fastabend <john.r.fastabend@intel.com> CC: Michael S. Tsirkin <mst@redhat.com> CC: Jason Wang <jasowang@redhat.com> Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com> Acked-by: NJohn Fastabend <john.r.fastabend@intel.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 21 8月, 2014 5 次提交
-
-
由 Jiri Kosina 提交于
There are a few very theoretical off-by-one bugs in report descriptor size checking when performing a pre-parsing fixup. Fix those. Cc: stable@vger.kernel.org Reported-by: NBen Hawkes <hawkes@google.com> Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Jiri Kosina 提交于
device_index is a char type and the size of paired_dj_deivces is 7 elements, therefore proper bounds checking has to be applied to device_index before it is used. We are currently performing the bounds checking in logi_dj_recv_add_djhid_device(), which is too late, as malicious device could send REPORT_TYPE_NOTIF_DEVICE_UNPAIRED early enough and trigger the problem in one of the report forwarding functions called from logi_dj_raw_event(). Fix this by performing the check at the earliest possible ocasion in logi_dj_raw_event(). Cc: stable@vger.kernel.org Reported-by: NBen Hawkes <hawkes@google.com> Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Jiri Kosina 提交于
The check on report size for REPORT_TYPE_LEDS in logi_dj_ll_raw_request() is wrong; the current check doesn't make any sense -- the report allocated by HID core in hid_hw_raw_request() can be much larger than DJREPORT_SHORT_LENGTH, and currently logi_dj_ll_raw_request() doesn't handle this properly at all. Fix the check by actually trimming down the report size properly if it is too large. Cc: stable@vger.kernel.org Reported-by: NBen Hawkes <hawkes@google.com> Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Mathias Nyman 提交于
It appears that input sensing bit might be reset during suspend/resume. Set input sensing again for all requested gpios in resume Tested-by: NJerome Blin <jerome.blin@intel.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
Once the CAN-bus is open and a packet is sent, the controller switches into the PASSIVE state. Once the BUS is closed again it goes the back err-warning. The TX error counter goes 0 -> 0x80 -> 0x7f. This patch makes sure that the user learns about this state chang (CAN_STATE_ERROR_WARNING => CAN_STATE_ERROR_PASSIVE) Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NMatthias Klein <matthias.klein@optimeas.de> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-