aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* PCI: use for_each_pci_dev()Kulikov Vasiliy2010-07-30
| | | | | | | Use for_each_pci_dev() to simplify the code. Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc()Ben Hutchings2010-07-30
| | | | | | | | | | | | | | | | | | | | commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 "PCI: MSI: Remove unsafe and unnecessary hardware access" changed read_msi_msg_desc() to return the last MSI message written instead of reading it from the device, since it may be called while the device is in a reduced power state. However, the pSeries platform code really does need to read messages from the device, since they are initially written by firmware. Therefore: - Restore the previous behaviour of read_msi_msg_desc() - Add new functions get_cached_msi_msg{,_desc}() which return the last MSI message written - Use the new functions where appropriate Acked-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: export SMBIOS provided firmware instance and label to sysfsNarendra K2010-07-30
| | | | | | | | | | | | | This patch exports SMBIOS provided firmware instance and label of onboard PCI devices to sysfs. New files are: /sys/bus/pci/devices/.../label which contains the firmware name for the device in question, and /sys/bus/pci/devices/.../index which contains the firmware device type instance for the given device. Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com> Signed-off-by: Narendra K <narendra_k@dell.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Allow read/write access to sysfs I/O port resourcesAlex Williamson2010-07-30
| | | | | | | | | | | PCI sysfs resource files currently only allow mmap'ing. On x86 this works fine for memory backed BARs, but doesn't work at all for I/O port backed BARs. Add read/write to I/O port PCI sysfs resource files to allow userspace access to these device regions. Acked-by: Chris Wright <chrisw@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* x86/PCI: use host bridge _CRS info on ASRock ALiveSATA2-GLANBjorn Helgaas2010-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This DMI quirk turns on "pci=use_crs" for the ALiveSATA2-GLAN because amd_bus.c doesn't handle this system correctly. The system has a single HyperTransport I/O chain, but has two PCI host bridges to buses 00 and 80. amd_bus.c learns the MMIO range associated with buses 00-ff and that this range is routed to the HT chain hosted at node 0, link 0: bus: [00, ff] on node 0 link 0 bus: 00 index 1 [mem 0x80000000-0xfcffffffff] This includes the address space for both bus 00 and bus 80, and amd_bus.c assumes it's all routed to bus 00. We find device 80:01.0, which BIOS left in the middle of that space, but we don't find a bridge from bus 00 to bus 80, so we conclude that 80:01.0 is unreachable from bus 00, and we move it from the original, working, address to something outside the bus 00 aperture, which does not work: pci 0000:80:01.0: reg 10: [mem 0xfebfc000-0xfebfffff 64bit] pci 0000:80:01.0: BAR 0: assigned [mem 0xfd00000000-0xfd00003fff 64bit] The BIOS told us everything we need to know to handle this correctly, so we're better off if we just pay attention, which lets us leave the 80:01.0 device at the original, working, address: ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f]) pci_root PNP0A03:00: host bridge window [mem 0x80000000-0xff37ffff] ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-ff]) pci_root PNP0A08:00: host bridge window [mem 0xfebfc000-0xfebfffff] This was a regression between 2.6.33 and 2.6.34. In 2.6.33, amd_bus.c was used only when we found multiple HT chains. 3e3da00c01d050, which enabled amd_bus.c even on systems with a single HT chain, caused this failure. This quirk was written by Graham. If we ever enable "pci=use_crs" for machines from 2006 or earlir, this quirk should be removed. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16007 Cc: stable@kernel.org Reported-by: Graham Ramsey <ramsey.graham@ntlworld.com> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: remove unused HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_{SIZE|BOUNDARY}FUJITA Tomonori2010-07-30
| | | | | | | | | | | | In 2.6.34, we transformed the PCI DMA API into the generic device mode. The PCI DMA API is just the wrapper of the DMA API. So we don't need HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_SIZE or HAVE_ARCH_PCI_SET_DMA_SEGMENT_BOUNDARY (which enable architectures to have the own implementations). Both haven't been used anyway. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: disable mmio during bar sizingJacob Pan2010-07-30
| | | | | | | | | | | | | | | | | It is a known issue that mmio decoding shall be disabled while doing PCI bar sizing. Host bridge and other devices (PCI PIC) shall be excluded for certain platforms. This patch mainly comes from Mathew Willcox's patch in http://kerneltrap.org/mailarchive/linux-kernel/2007/9/13/258969. A new flag bit "mmio_alway_on" is added to pci_dev with the intention that devices with their mmio decoding cannot be disabled during BAR sizing shall have this bit set, preferrablly in their quirks. Without this patch, Intel Moorestown platform graphics unit will be corrupted during bar sizing activities. Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: MSI: Remove unsafe and unnecessary hardware accessBen Hutchings2010-07-30
| | | | | | | | | | | | | | | | | | | | | During suspend on an SMP system, {read,write}_msi_msg_desc() may be called to mask and unmask interrupts on a device that is already in a reduced power state. At this point memory-mapped registers including MSI-X tables are not accessible, and config space may not be fully functional either. While a device is in a reduced power state its interrupts are effectively masked and its MSI(-X) state will be restored when it is brought back to D0. Therefore these functions can simply read and write msi_desc::msg for devices not in D0. Further, read_msi_msg_desc() should only ever be used to update a previously written message, so it can always read msi_desc::msg and never needs to touch the hardware. Tested-by: "Michael Chan" <mchan@broadcom.com> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Default PCIe ASPM control to on and require !EMBEDDED to disableMatthew Garrett2010-07-30
| | | | | | | | | | | | | | | | | | | | | The CONFIG_PCIEASPM option is confusing and potentially dangerous. ASPM is a hardware mediated feature rather than one under direct OS control, and even if the config option is disabled the system firmware may have turned on ASPM on various bits of hardware. This can cause problems later - various hardware that claims to support ASPM does a poor job of it and may hang or cause other difficulties. The kernel is able to recognise this in many cases and disable the ASPM functionality, but only if CONFIG_PCIEASPM is enabled. Given that in its default configuration this option will either leave the hardware as it was originally or disable hardware functionality that may cause problems, it should by default y. The only reason to disable it ought to be to reduce code size, so make it dependent on CONFIG_EMBEDDED. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: lrodriguez@atheros.com Cc: maximlevitsky@gmail.com Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: kernel oops on access to pci proc file while hot-removalKenji Kaneshige2010-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I encountered the problem that /proc/bus/pci/XX/YY is not removed even after the corresponding device is hot-removed, if the file is still being opened. In addtion, accessing this file in this situation causes kernel panic (see below). Becasue the pci_proc_detach_device() doesn't call remove_proc_entry() if struct proc_dir_entry->count > 1, access to /proc/bus/pci/XX/YY would refer to struct pci_dev that was already freed. Though I don't know why the check for proc_dir_entry->count was added, I don't think it is needed. Removing this check fixes the problem. Steps to reproduce ------------------ # cd /sys/bus/pci/slots/2/ # PROC_BUS_PCI_FILE=/proc/bus/pci/`awk -F: '{print $2"/"$3}' < address`.0 # sleep 10000 < $PROC_BUS_PCI_FILE & # echo 0 > power # while true; do cat $PROC_BUS_PCI_FILE > /dev/null; done Oops Messages ------------- BUG: unable to handle kernel NULL pointer dereference at 00000042 IP: [<c05c82d5>] pci_user_read_config_dword+0x65/0xa0 *pdpt = 000000002185e001 *pde = 0000000476a79067 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1c.0/0000:10:00.0/local_cpus Modules linked in: autofs4 sunrpc cpufreq_ondemand acpi_cpufreq ipv6 dm_mirror dm_region_hash dm_log dm_mod e1000e i2c_i801 i2c_core iTCO_wdt igb sg pcspkr dca iTCO_vendor_support ext4 mbcache jbd2 sd_mod crc_t10dif lpfc mptsas scsi_transport_fc mptscsih mptbase scsi_tgt scsi_transport_sas [last unloaded: microcode] Pid: 2997, comm: cat Not tainted 2.6.34-kk #32 SB/PRIMEQUEST 1800E EIP: 0060:[<c05c82d5>] EFLAGS: 00010046 CPU: 19 EIP is at pci_user_read_config_dword+0x65/0xa0 EAX: 00000002 EBX: e44f1800 ECX: e144df14 EDX: 155668c7 ESI: 00000087 EDI: 00000000 EBP: e144df40 ESP: e144df0c DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process cat (pid: 2997, ti=e144c000 task=e26f2570 task.ti=e144c000) Stack: c09ceac0 c0570f72 ffffffff 08c57000 00000000 00001000 e44f1800 c05d2404 <0> e144df40 00001000 00000000 00001000 08c57000 3093ae50 e420cb40 e358d5c0 <0> c05d2300 fffffffb c054984f e144df9c 00008000 08c57000 e358d5c0 00008000 Call Trace: [<c0570f72>] ? security_capable+0x22/0x30 [<c05d2404>] ? proc_bus_pci_read+0x104/0x220 [<c05d2300>] ? proc_bus_pci_read+0x0/0x220 [<c054984f>] ? proc_reg_read+0x5f/0x90 [<c05497f0>] ? proc_reg_read+0x0/0x90 [<c050694d>] ? vfs_read+0x9d/0x190 [<c04958f4>] ? audit_syscall_entry+0x204/0x230 [<c0506a81>] ? sys_read+0x41/0x70 [<c0402f1f>] ? sysenter_do_call+0x12/0x28 Code: b4 26 00 00 00 00 b8 20 88 b1 c0 c7 44 24 08 ff ff ff ff e8 3e 52 22 00 f6 83 24 04 00 00 20 75 34 8b 43 08 8d 4c 24 08 8b 53 1c <8b> 70 40 89 4c 24 04 89 f9 c7 04 24 04 00 00 00 ff 16 89 c6 f0 EIP: [<c05c82d5>] pci_user_read_config_dword+0x65/0xa0 SS:ESP 0068:e144df0c CR2: 0000000000000042 Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: pci-sysfs: remove casts from void*Kulikov Vasiliy2010-07-30
| | | | | | | Remove unnesessary casts from void*. Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ACPI: Disable ASPM if the platform won't provide _OSC control for PCIeMatthew Garrett2010-07-30
| | | | | | | | | | | | | | | | | | | | | | | | The PCI SIG documentation for the _OSC OS/firmware handshaking interface states: "If the _OSC control method is absent from the scope of a host bridge device, then the operating system must not enable or attempt to use any features defined in this section for the hierarchy originated by the host bridge." The obvious interpretation of this is that the OS should not attempt to use PCIe hotplug, PME or AER - however, the specification also notes that an _OSC method is *required* for PCIe hierarchies, and experimental validation with An Alternative OS indicates that it doesn't use any PCIe functionality if the _OSC method is missing. That arguably means we shouldn't be using MSI or extended config space, but right now our problems seem to be limited to vendors being surprised when ASPM gets enabled on machines when other OSs refuse to do so. So, for now, let's just disable ASPM if the _OSC method doesn't exist or refuses to hand over PCIe capability control. Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI hotplug: make sure child bridges are enabled at hotplug timeYinghai Lu2010-07-30
| | | | | | | | | | | | | | | | Found one PCIe Module with several bridges built-in where a "cold" hotadd doesn't work. If we end up reassigning bridge windows at hotadd time, and have to loop through assigning new ranges, we won't end up enabling the child bridges because the first assignment pass already tried to enable them, which prevents __pci_bridge_assign_resource from updating the windows. So try to move enabling of child bridges to the end, and only do it once. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI hotplug: shpchp: Removed check for hotplug of display devicesPraveen Kalamegham2010-07-30
| | | | | | | | | | | | Removed check to prevent hotplug of display devices within shpchp. Originally this was thought to have been required within the PCI Hotplug specification for some legacy devices. However there is no such requirement in the most recent revision. The check prevents hotplug of not only display devices but also computational GPUs which require serviceability. Signed-off-by: Praveen Kalamegham <praveen@nextio.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI hotplug: pciehp: Fixed return value sign for pciehp_unconfigure_devicePraveen Kalamegham2010-07-30
| | | | | | | pciehp_unconfigure_device() should return -EINVAL, not EINVAL. Signed-off-by: Praveen Kalamegham <praveen@nextio.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Don't enable aspm before drivers have had a chance to veto itMatthew Garrett2010-07-30
| | | | | | | | | | | | | | The aspm code will currently set the configured aspm policy before drivers have had an opportunity to indicate that their hardware doesn't support it. Unfortunately, putting some hardware in L0 or L1 can result in the hardware no longer responding to any requests, even after aspm is disabled. It makes more sense to leave aspm policy at the BIOS defaults at initial setup time, reconfiguring it after pci_enable_device() is called. This allows the driver to blacklist individual devices beforehand. Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: fix wrong memory address handling in MSI-XKenji Kaneshige2010-07-30
| | | | | | | | | Use resource_size_t for MMIO address instead of unsigned long. Otherwise, higher 32-bits of MMIO address are cleared unexpectedly in x86-32 PAE. Acked-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: check return value of pci_enable_device() when enabling bridgesJunchang Wang2010-07-30
| | | | | | | | | pci_enable_device can fail. In that case, a printed warning would be more appropriate. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> Signed-off-by: Junchang Wang <junchangwang@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: sparse warning (trivial)Stephen Hemminger2010-07-30
| | | | | | | Assigning zero where NULL should be used. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* x86/PCI: Add option to not assign BAR's if not already assignedMike Habeck2010-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | The Linux kernel assigns BARs that a BIOS did not assign, most likely to handle broken BIOSes that didn't enumerate the devices correctly. On UV the BIOS purposely doesn't assign I/O BARs for certain devices/ drivers we know don't use them (examples, LSI SAS, Qlogic FC, ...). We purposely don't assign these I/O BARs because I/O Space is a very limited resource. There is only 64k of I/O Space, and in a PCIe topology that space gets divided up into 4k chucks (this is due to the fact that a pci-to-pci bridge's I/O decoder is aligned at 4k)... Thus a system can have at most 16 cards with I/O BARs: (64k / 4k = 16) SGI needs to scale to >16 devices with I/O BARs. So by not assigning I/O BARs on devices we know don't use them, we can do that (iff the kernel doesn't go and assign these BARs that the BIOS purposely didn't assign). This patch will not assign a resource to a device BAR if that BAR was not assigned by the BIOS, and the kernel cmdline option 'pci=nobar' was specified. This patch is closely modeled after the 'pci=norom' option that currently exists in the tree. Signed-off-by: Mike Habeck <habeck@sgi.com> Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: disable MSI on VIA K8M800Tejun Heo2010-07-30
| | | | | | | | | | | | MSI delivery from on-board ahci controller doesn't work on K8M800. At this point, it's unclear whether the culprit is with the ahci controller or the host bridge. Given the track record and considering the rather minimal impact of MSI, disabling it seems reasonable. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Rainer Hurtado Navarro <publio.escipion.el.africano@gmail.com> Cc: stable@kernel.org Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI quirk: AMD 780: work around wrong vendor ID on APC bridgeClemens Ladisch2010-07-30
| | | | | | | | | | | | | | | | | | | In all AMD 780 family northbridges, the vendor ID of the internal graphics PCI/PCI bridge reads not as AMD but as that of the mainboard vendor, because the hardware actually returns the value of the subsystem vendor ID (erratum 18). We currently have additional quirk entries for Asus and Acer, but it is likely that we will encounter more systems with other vendor IDs. Since we do not know in advance all possible vendor IDs, a better way to find the device is to declare the quirk on the host bridge, whose ID is always correct, and use that device as a stepping stone to find the PCI/ PCI bridge, if present. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: hotplug/shpchp_hpc: add parenthesis in SLOT_REG_RSVDZ_MASKDan Carpenter2010-07-30
| | | | | | | | | | | The SLOT_REG_RSVDZ_MASK macro is normally used like this: slot_reg &= ~SLOT_REG_RSVDZ_MASK; The ~ operator has higher precedence than the | operator from inside the macro, so it needs parenthesis. Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI aerdrv: fix annoying warningsLinus Torvalds2010-07-30
| | | | | | | | | | | | | | | | Some compiler generates following warnings: In function 'aer_isr': warning: 'e_src.id' may be used uninitialized in this function warning: 'e_src.status' may be used uninitialized in this function Avoid status flag "int ret" and return constants instead, so that gcc sees the return value matching "it is initialized" better. Acked-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* x86/PCI: pci, fix section mismatchJiri Slaby2010-07-30
| | | | | | | | | pcibios_scan_specific_bus calls pci_scan_bus_on_node which is __devinit. Mark pcibios_scan_specific_bus __devinit as well since all users are now __init or __devinit. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: change device runtime PM settings for probe and removeAlan Stern2010-07-30
| | | | | | | | | | | | | | | | | | | | | | This patch (as1388) changes the way the PCI core handles runtime PM settings when probing or unbinding drivers. Now the core will make sure the device is enabled for runtime PM, with a usage count >= 1, when a driver is probed. It does the same when calling a driver's remove method. If the driver wants to use runtime PM, all it has to do is call pm_runtime_pu_noidle() near the end of its probe routine (to cancel the core's usage increment) and pm_runtime_get_noresume() near the start of its remove routine (to restore the usage count). It does not need to mess around with setting the runtime state to enabled, disabled, active, or suspended. The patch updates e1000e and r8169, the only PCI drivers that already use the existing runtime PM interface. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* Merge branch 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6Linus Torvalds2010-07-29
|\ | | | | | | | | | | * 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6: [S390] etr: fix clock synchronization race [S390] Fix IRQ tracing in case of PER
| * [S390] etr: fix clock synchronization raceMartin Schwidefsky2010-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The etr events switch-to-local and sync-check disable the synchronous clock and schedule a work queue that tries to get the clock back into sync. If another switch-to-local or sync-check event occurs while the work queue function etr_work_fn still runs the eacr.es bit and the clock_sync_word can become inconsistent because check_sync_clock only uses the clock_sync_word to determine if the clock is in sync or not. The second pass of the etr_work_fn will reset the eacr.es bit but will leave the clock_sync_word intact. Fix this race by moving the reset of the eacr.es bit into the switch-to-local and sync-check functions and by checking the eacr.es bit as well to decide if the clock needs to be synced. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
| * [S390] Fix IRQ tracing in case of PERHeiko Carstens2010-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | In case user space is single stepped (PER) the program check handler claims too early that IRQs are enabled on the return path. Subsequent checks will notice that the IRQ mask in the PSW and what lockdep thinks the IRQ mask should be do not correlate and therefore will print a warning to the console and disable lockdep. Fix this by doing all the work within the correct context. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdogLinus Torvalds2010-07-29
|\ \ | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog: watchdog: update MAINTAINERS entry
| * | watchdog: update MAINTAINERS entryWim Van Sebroeck2010-07-29
| | | | | | | | | | | | | | | | | | Add Mailing-list and website to watchdog MAINTAINERS entry. Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
* | | Merge branch 'fix/hda' of ↵Linus Torvalds2010-07-29
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 * 'fix/hda' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6: ALSA: hda - Add a PC-beep workaround for ASUS P5-V ALSA: hda - Assume PC-beep as default for Realtek ALSA: hda - Don't register beep input device when no beep is available ALSA: hda - Fix pin-detection of Nvidia HDMI
| * | | ALSA: hda - Add a PC-beep workaround for ASUS P5-VTakashi Iwai2010-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ASUS P5-V provides a SSID that unexpectedly matches with the value compilant with Realtek's specification. Thus the driver interprets it badly, resulting in non-working PC beep. This patch adds a white-list for such a case; a white-list of known devices with working PC beep. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | | ALSA: hda - Assume PC-beep as default for RealtekTakashi Iwai2010-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable PC-beep as default for hardwares that aren't compliant with the SSID value Realtek requires. In such a case, better to enable the beep to avoid a regression. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | | ALSA: hda - Don't register beep input device when no beep is availableTakashi Iwai2010-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We check now the availability of PC beep and skip the build of beep mixers, but the driver still registers the input device. This should be checked as well. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * | | ALSA: hda - Fix pin-detection of Nvidia HDMITakashi Iwai2010-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The behavior of Nvidia HDMI codec regarding the pin-detection unsol events is based on the old HD-audio spec, i.e. PD bit indicates only the update and doesn't show the current state. Since the current code assumes the new behavior, the pin-detection doesn't work relialby with these h/w. This patch adds a flag for indicating the old spec, and fixes the issue by checking the pin-detection explicitly for such hardware. Tested-by: Wei Ni <wni@nvidia.com> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | | CRED: Fix __task_cred()'s lockdep check and banner commentDavid Howells2010-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix __task_cred()'s lockdep check by removing the following validation condition: lockdep_tasklist_lock_is_held() as commit_creds() does not take the tasklist_lock, and nor do most of the functions that call it, so this check is pointless and it can prevent detection of the RCU lock not being held if the tasklist_lock is held. Instead, add the following validation condition: task->exit_state >= 0 to permit the access if the target task is dead and therefore unable to change its own credentials. Fix __task_cred()'s comment to: (1) discard the bit that says that the caller must prevent the target task from being deleted. That shouldn't need saying. (2) Add a comment indicating the result of __task_cred() should not be passed directly to get_cred(), but rather than get_task_cred() should be used instead. Also put a note into the documentation to enforce this point there too. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | | CRED: Fix get_task_cred() and task_state() to not resurrect dead credentialsDavid Howells2010-07-29
| |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's possible for get_task_cred() as it currently stands to 'corrupt' a set of credentials by incrementing their usage count after their replacement by the task being accessed. What happens is that get_task_cred() can race with commit_creds(): TASK_1 TASK_2 RCU_CLEANER -->get_task_cred(TASK_2) rcu_read_lock() __cred = __task_cred(TASK_2) -->commit_creds() old_cred = TASK_2->real_cred TASK_2->real_cred = ... put_cred(old_cred) call_rcu(old_cred) [__cred->usage == 0] get_cred(__cred) [__cred->usage == 1] rcu_read_unlock() -->put_cred_rcu() [__cred->usage == 1] panic() However, since a tasks credentials are generally not changed very often, we can reasonably make use of a loop involving reading the creds pointer and using atomic_inc_not_zero() to attempt to increment it if it hasn't already hit zero. If successful, we can safely return the credentials in the knowledge that, even if the task we're accessing has released them, they haven't gone to the RCU cleanup code. We then change task_state() in procfs to use get_task_cred() rather than calling get_cred() on the result of __task_cred(), as that suffers from the same problem. Without this change, a BUG_ON in __put_cred() or in put_cred_rcu() can be tripped when it is noticed that the usage count is not zero as it ought to be, for example: kernel BUG at kernel/cred.c:168! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/kernel/mm/ksm/run CPU 0 Pid: 2436, comm: master Not tainted 2.6.33.3-85.fc13.x86_64 #1 0HR330/OptiPlex 745 RIP: 0010:[<ffffffff81069881>] [<ffffffff81069881>] __put_cred+0xc/0x45 RSP: 0018:ffff88019e7e9eb8 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffff880161514480 RCX: 00000000ffffffff RDX: 00000000ffffffff RSI: ffff880140c690c0 RDI: ffff880140c690c0 RBP: ffff88019e7e9eb8 R08: 00000000000000d0 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000040 R12: ffff880140c690c0 R13: ffff88019e77aea0 R14: 00007fff336b0a5c R15: 0000000000000001 FS: 00007f12f50d97c0(0000) GS:ffff880007400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8f461bc000 CR3: 00000001b26ce000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process master (pid: 2436, threadinfo ffff88019e7e8000, task ffff88019e77aea0) Stack: ffff88019e7e9ec8 ffffffff810698cd ffff88019e7e9ef8 ffffffff81069b45 <0> ffff880161514180 ffff880161514480 ffff880161514180 0000000000000000 <0> ffff88019e7e9f28 ffffffff8106aace 0000000000000001 0000000000000246 Call Trace: [<ffffffff810698cd>] put_cred+0x13/0x15 [<ffffffff81069b45>] commit_creds+0x16b/0x175 [<ffffffff8106aace>] set_current_groups+0x47/0x4e [<ffffffff8106ac89>] sys_setgroups+0xf6/0x105 [<ffffffff81009b02>] system_call_fastpath+0x16/0x1b Code: 48 8d 71 ff e8 7e 4e 15 00 85 c0 78 0b 8b 75 ec 48 89 df e8 ef 4a 15 00 48 83 c4 18 5b c9 c3 55 8b 07 8b 07 48 89 e5 85 c0 74 04 <0f> 0b eb fe 65 48 8b 04 25 00 cc 00 00 48 3b b8 58 04 00 00 75 RIP [<ffffffff81069881>] __put_cred+0xc/0x45 RSP <ffff88019e7e9eb8> ---[ end trace df391256a100ebdd ]--- Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | Merge branch 'for_linus' of ↵Linus Torvalds2010-07-28
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb: x86,kgdb: Fix hw breakpoint regression
| * | | x86,kgdb: Fix hw breakpoint regressionJason Wessel2010-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HW breakpoints events stopped working correctly with kgdb as a result of commit: 018cbffe6819f6f8db20a0a3acd9bab9bfd667e4 (Merge commit 'v2.6.33' into perf/core). The regression occurred because the behavior changed for setting NOTIFY_STOP as the return value to the die notifier if the breakpoint was known to the HW breakpoint API. Because kgdb is using the HW breakpoint API to register HW breakpoints slots, it must also now implement the overflow_handler call back else kgdb does not get to see the events from the die notifier. The kgdb_ll_trap function will be changed to be general purpose code which can allow an easy way to implement the hw_breakpoint API overflow call back. Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Acked-by: Dongdong Deng <dongdong.deng@windriver.com> Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
* | | | Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6Linus Torvalds2010-07-28
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: [SCSI] ibmvscsi: Fix oops when an interrupt is pending during probe [SCSI] zfcp: Update status read mempool [SCSI] zfcp: Do not wait for SBALs on stopped queue [SCSI] zfcp: Fix check whether unchained ct_els is possible [SCSI] ipr: fix resource path display and formatting
| * | | | [SCSI] ibmvscsi: Fix oops when an interrupt is pending during probeAnton Blanchard2010-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A driver needs to be ready to take an interrupt as soon as it registers an interrupt handler. I noticed the following oops when testing kdump: ipr: IBM Power RAID SCSI Device Driver version: 2.5.0 (February 11, 2010) ibmvscsi 30000002: SRP_VERSION: 16.a ibmvscsi 30000002: SRP_VERSION: 16.a Unable to handle kernel paging request for data at address 0x00000000 ... pc: c000000004085e34: .tasklet_action+0xf4/0x1dc ... c000000004086fe4 .__do_softirq+0x16c/0x2c0 c00000000403138c .call_do_softirq+0x14/0x24 c00000000400ee14 .do_softirq+0xa0/0x104 c00000000408690c .irq_exit+0x70/0xd0 c00000000400f190 .do_IRQ+0x214/0x2a8 c000000004004804 hardware_interrupt_entry+0x1c/0x98 --- Exception: 501 (Hardware Interrupt) at c00000000400c544 .raw_local_irq_restore+0x48/0x54 c00000000465d2a8 ._raw_spin_unlock_irqrestore+0x74/0xa0 c0000000040e7f00 .__setup_irq+0x2ec/0x3f0 c0000000040e8198 .request_threaded_irq+0x194/0x22c c00000000446d854 .rpavscsi_init_crq_queue+0x284/0x3f0 c00000000446c764 .ibmvscsi_probe+0x688/0x710 c00000000402903c .vio_bus_probe+0x37c/0x3e4 c000000004403f10 .driver_probe_device+0xec/0x1b8 c000000004404088 .__driver_attach+0xac/0xf4 c000000004403184 .bus_for_each_dev+0x98/0x104 c000000004403c98 .driver_attach+0x40/0x60 c0000000044026f0 .bus_add_driver+0x154/0x324 c0000000044045d0 .driver_register+0xe8/0x1ac c00000000402b2a8 .vio_register_driver+0x54/0x74 c000000004933ea4 .ibmvscsi_module_init+0x80/0xc0 c000000004009834 .do_one_initcall+0x98/0x1d8 c0000000049005b4 .kernel_init+0x27c/0x33c c000000004031550 .kernel_thread+0x54/0x70 srp_task needs to be setup before request_irq. The patch below fixes the oops. Signed-off-by: Anton Blanchard <anton@samba.org> Acked-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
| * | | | [SCSI] zfcp: Update status read mempoolChristof Schmitt2010-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 64deb6efdc5504ce97b5c1c6f281fffbc150bd93 changed the way status read buffers are handled but forgot to adjust the mempool to the new size. Add the call to resize the mempool after the exchange config data. Also use the define instead of the hard coded number in the fsf callback for consistency. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
| * | | | [SCSI] zfcp: Do not wait for SBALs on stopped queueChristof Schmitt2010-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trying to read the FC host statistics on an offline adapter results in a 5 seconds wait. Reading the statistics tries to issue an exchange port data request which first waits up to 5 seconds for an entry in the request queue. Change the strategy for getting a free SBAL to exit when the queue is stopped. Reading the statistics will then fail without the wait. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
| * | | | [SCSI] zfcp: Fix check whether unchained ct_els is possibleSwen Schillig2010-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A false check was performed whether an unchained ct_els is possible or not. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
| * | | | [SCSI] ipr: fix resource path display and formattingWayne Boyer2010-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was possible to overflow the buffer used to print out the formatted version of the resource path. The fix is to limit the number of bytes that get formatted. This patch also updates the ipr_show_resource_path function to display the resource address for devices that are attached to adapters that don't support resource paths. Signed-off-by: Wayne Boyer <wayneb@linux.vnet.ibm.com> Acked-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
* | | | | Merge branch 'for-linus' of ↵Linus Torvalds2010-07-28
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6: davinci: da850/omap-l138 evm: account for DEFDCDC{2,3} being tied high regulator: tps6507x: allow driver to use DEFDCDC{2,3}_HIGH register wm8350-regulator: fix wm8350_register_regulator error handling ab3100: fix off-by-one value range checking for voltage selector
| * | | | | davinci: da850/omap-l138 evm: account for DEFDCDC{2,3} being tied highSekhar Nori2010-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Per the da850/omap-l138 Beta EVM SOM schematic, the DEFDCDC2 and DEFDCDC3 lines are tied high. This leads to a 3.3V IO and 1.2V CVDD voltage. Pass the right platform data to the TPS6507x driver so it can operate on the DEFDCDC{2,3}_HIGH register to read and change voltage levels. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | | | regulator: tps6507x: allow driver to use DEFDCDC{2,3}_HIGH registerAnuj Aggarwal2010-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> In TPS6507x, depending on the status of DEFDCDC{2,3} pin either DEFDCDC{2,3}_LOW or DEFDCDC{2,3}_HIGH register needs to be read or programmed to change the output voltage. The current driver assumes DEFDCDC{2,3} pins are always tied low and thus operates only on DEFDCDC{2,3}_LOW register. This need not always be the case (as is found on OMAP-L138 EVM). Unfortunately, software cannot read the status of DEFDCDC{2,3} pins. So, this information is passed through platform data depending on how the board is wired. Signed-off-by: Anuj Aggarwal <anuj.aggarwal@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
| * | | | | wm8350-regulator: fix wm8350_register_regulator error handlingAxel Lin2010-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the case of platform_device_add() fail, we should call platform_device_put() instead of platform_device_del() Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-18 16:21:01 -0500