linux/drivers/pci, branch mybooklive

gpl-source-mybooklive-010002-update.zip

2014-08-13T21:14:13Z

PCI: cleanup error return for pcix get and set mmrbc functions

2010-04-01T22:58:45Z

commit 7c9e2b1c4784c6e574f69dbd904b2822f2e04d6e upstream. pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if successful, or an appropriate error value, if not. Distinguishing errors from correct values and understanding the meaning of an error can be somewhat confusing in that: correct values: 512, 1024, 2048, 4096 errors: -EINVAL -22 PCIBIOS_FUNC_NOT_SUPPORTED 0x81 PCIBIOS_BAD_VENDOR_ID 0x83 PCIBIOS_DEVICE_NOT_FOUND 0x86 PCIBIOS_BAD_REGISTER_NUMBER 0x87 PCIBIOS_SET_FAILED 0x88 PCIBIOS_BUFFER_TOO_SMALL 0x89 The PCIBIOS_ errors are returned from the PCI functions generated by the PCI_OP_READ() and PCI_OP_WRITE() macros. In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values returned from pci_read_config_[word|dword]() and pci_write_config_word(). Following pcix_get_max_mmrbc()'s example, the following patch simply returns -EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL or -EIO for those encountered by pcix_set_mmrbc(). This simplification was chosen in light of the fact that none of the current callers of these functions are interested in the specific type of error encountered. In the future, should this change, one could simply create a function that maps each PCIBIOS_ error to a corresponding unique errno value, which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and pcix_set_mmrbc(). Additionally, this patch eliminates some unnecessary variables. Signed-off-by: Dean Nelson Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

PCI: fix access of PCI_X_CMD by pcix get and set mmrbc functions

2010-04-01T22:58:45Z

commit bdc2bda7c4dd253026cc1fce45fc939304749029 upstream. An e1000 driver on a system with a PCI-X bus was always being returned a value of 135 from both pcix_get_mmrbc() and pcix_set_mmrbc(). This value reflects an error return of PCIBIOS_BAD_REGISTER_NUMBER from pci_bus_read_config_dword(,, cap + PCI_X_CMD,). This is because for a dword, the following portion of the PCI_OP_READ() macro: if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; expands to: if (pos & 3) return PCIBIOS_BAD_REGISTER_NUMBER; And is always true for 'cap + PCI_X_CMD', which is 0xe4 + 2 = 0xe6. ('cap' is the result of calling pci_find_capability(, PCI_CAP_ID_PCIX).) The same problem exists for pci_bus_write_config_dword(,, cap + PCI_X_CMD,). In both cases, instead of calling _dword(), _word() should be called. Signed-off-by: Dean Nelson Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

PCI: fix return value from pcix_get_max_mmrbc()

2010-04-01T22:58:44Z

commit 25daeb550b69e89aff59bc6a84218a12b5203531 upstream. For the PCI_X_STATUS register, pcix_get_max_mmrbc() is returning an incorrect value, which is based on: (stat & PCI_X_STATUS_MAX_READ) >> 12 Valid return values are 512, 1024, 2048, 4096, which correspond to a 'stat' (masked and right shifted by 21) of 0, 1, 2, 3, respectively. A right shift by 11 would generate the correct return value when 'stat' (masked and right shifted by 21) has a value of 1 or 2. But for a value of 0 or 3 it's not possible to generate the correct return value by only right shifting. Fix is based on pcix_get_mmrbc()'s similar dealings with the PCI_X_CMD register. Signed-off-by: Dean Nelson Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

pci: add support for 82576NS serdes to existing SR-IOV quirk

2010-04-01T22:58:15Z

commit 7a0deb6bcda98c2a764cb87f1441eef920fd3663 upstream. This patch adds support for the 82576NS Serdes adapter to the existing pci quirk for 82576 parts. Signed-off-by: Alexander Duyck Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

PCI: unconditionally clear AER uncorr status register during cleanup

2010-04-01T22:58:12Z

commit 6cdfd995a65a52e05b99e3a72a9b979abe73b312 upstream. The current implementation of pci_cleanup_aer_uncorrect_error_status only clears either fatal or non-fatal error status bits depending on the state of the I/O channel. This implementation will then often leave some bits set after PCI error recovery completes. The uncleared bit settings will then be falsely reported the next time an AER interrupt is generated for that hierarchy. An easy way to illustrate this issue is to use the aer-inject module to simultaneously inject both an uncorrectable non-fatal and uncorrectable fatal error. One of the errors will not be cleared. This patch resolves this issue by unconditionally clearing all bits in the AER uncorrectable status register. All settings and corrective action strategies are saved and determined before pci_cleanup_aer_uncorrect_error_status is called, so this change should not affect errory handling functionality. Signed-off-by: Andrew Patterson Signed-off-by: Jesse Barnes Cc: Alex Chiang Signed-off-by: Greg Kroah-Hartman

PCI hotplug: check ioremap() return value in ibmphp_ebda.c

2010-03-15T15:49:35Z

commit ba02b242bbf8e4e1bc63d62e8ccec33b4e5ea132 upstream. check ioremap() return value. Signed-off-by: Andrew Morton Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

PCI hotplug: ibmphp: read the length of ebda and map entire ebda region

2010-03-15T15:49:35Z

commit b0fc889c4311835ae7d02f433154bc20cad9ee11 upstream. ibmphp driver currently maps only 1KB of ebda memory area into kernel address space during driver initialization. This causes kernel oops when the driver is modprobe'd and it accesses memory beyond 1KB within ebda segment. The first byte of ebda segment actually stores the length of the ebda region in Kilobytes. Hence make use of the length parameter and map the entire ebda region. Signed-off-by: Chandru Siddalingappa Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

PCI: AER: fix aer inject result in kernel oops

2010-01-28T23:01:51Z

commit 46256f83d0d066f99ffde547f27473dfd2a78009 upstream. If the BIOS does not export _OSC to allow OS take over the PCIe AER, the pcie aer driver will not initialize the aer service. However, the aer_inject driver does not check this scenario, which results in a kernel oops when injecting an aer error into OS. For example: BUG: unable to handle kernel NULL pointer dereference at 0000000000000350 IP: [] _spin_lock_irqsave+0xc/0x23 PGD 155c41067 PUD 157fe0067 PMD 0 Oops: 0002 [#1] SMP Pid: 5119, comm: aer-inject Not tainted 2.6.32-rc8-mce #2 RIP: 0010:[] [] _spin_lock_irqsave+0xc/0x23 RSP: 0018:ffff880157f81e28 EFLAGS: 00010096 RAX: 0000000000000296 RBX: 0000000000000000 RCX: 0000000000000100 RDX: 0000000000010000 RSI: 0000000000000246 RDI: 0000000000000350 RBP: ffff880157f81e28 R08: 0000000000000004 R09: ffff880157f81dac R10: ffff88015a666f60 R11: ffff88015a666f40 R12: ffff88015758cc00 R13: 0000000000000350 R14: 0000000000000000 R15: 0000000000000100 FS: 00007f4d4a66e6f0(0000) GS:ffff8800282e0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000350 CR3: 000000015661a000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process aer-inject (pid: 5119, threadinfo ffff880157f80000, task ffff8801585f4340) Stack: ffff880157f81e78 ffffffff811b1615 ffff880157f81e78 ffffffff81222823 Call Trace: [] aer_irq+0x38/0x117 [] ? device_for_each_child+0x5f/0x6f [] aer_inject_write+0x409/0x45e [aer_inject] [] vfs_write+0xae/0x16a [] sys_write+0x47/0x6e [] system_call_fastpath+0x16/0x1b RIP [] _spin_lock_irqsave+0xc/0x23 RSP CR2: 0000000000000350 So check the _OSC before assuming that AER is available to the OS. Signed-off-by: Song Youquan Acked-by: Huang Ying Signed-off-by: Jesse Barnes Signed-off-by: Thomas Renninger Signed-off-by: Greg Kroah-Hartman

PCI: Always set prefetchable base/limit upper32 registers

2010-01-28T23:01:15Z

commit 59353ea30e65ab3ae181d6175e3212e1361c3787 upstream. Prior to 1f82de10 we always initialized the upper 32bits of the prefetchable memory window, regardless of the address range used. Now we only touch it for a >32bit address, which means the upper32 registers remain whatever the BIOS initialized them too. It's valid for the BIOS to set the upper32 base/limit to 0xffffffff/0x00000000, which makes us program prefetchable ranges like 0xffffffffabc00000 - 0x00000000abc00000 Revert the chunk of 1f82de10 that made this conditional so we always write the upper32 registers and remove now unused pref_mem64 variable. Signed-off-by: Alex Williamson Signed-off-by: Jesse Barnes Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman