- 21 4月, 2008 19 次提交
-
-
由 Ben Hutchings 提交于
Vital Product Data (VPD) may be exposed by PCI devices in several ways. It is generally unsafe to read this information through the existing interfaces to user-land because of stateful interfaces. This adds: - abstract operations for VPD access (struct pci_vpd_ops) - VPD state information in struct pci_dev (struct pci_vpd) - an implementation of the VPD access method specified in PCI 2.2 (in access.c) - a 'vpd' binary file in sysfs directories for PCI devices with VPD operations defined It adds a probe for PCI 2.2 VPD in pci_scan_device() and release of VPD state in pci_release_dev(). Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 mark gross 提交于
This patch is for batching up the flushing of the IOTLB for the DMAR implementation found in the Intel VT-d hardware. It works by building a list of to be flushed IOTLB entries and a bitmap list of which DMAR engine they are from. After either a high water mark (250 accessible via debugfs) or 10ms the list of iova's will be reclaimed and the DMAR engines associated are IOTLB-flushed. This approach recovers 15 to 20% of the performance lost when using the IOMMU for my netperf udp stream benchmark with small packets. It can be disabled with a kernel boot parameter "intel_iommu=strict". Its use does weaken the IOMMU protections a bit. Signed-off-by: NMark Gross <mgross@linux.intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Bjorn Helgaas 提交于
print_fn_descriptor_symbol() prints the address if we don't have a symbol, so no need to print both. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 mark gross 提交于
The following patch merges two functions into one allowing for a 3% reduction in overhead in locating, allocating and inserting pages for use in IOMMU operations. Its a bit of a eye-crosser so I welcome any RB-tree / MM experts to take a look. It works by re-using some of the information gathered in the search for the pages to use in setting up the IOTLB's in the insertion of the iova structure into the RB tree. Signed-off-by: <mgross@linux.intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Bjorn Helgaas 提交于
Each architecture has its own pcibios_enable_resources() implementation. These differ in many minor ways that have nothing to do with actual architectural differences. Follow-on patches will make most arches use this generic version instead. This version is based on powerpc, which seemed most up-to-date. The only functional difference from the x86 version is that this uses "!r->parent" to check for resource collisions instead of "!r->start && r->end". Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: NDavid Howells <dhowells@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Shaohua Li 提交于
PCI Express ASPM defines a protocol for PCI Express components in the D0 state to reduce Link power by placing their Links into a low power state and instructing the other end of the Link to do likewise. This capability allows hardware-autonomous, dynamic Link power reduction beyond what is achievable by software-only controlled power management. However, The device should be configured by software appropriately. Enabling ASPM will save power, but will introduce device latency. This patch adds ASPM support in Linux. It introduces a global policy for ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control it. The interface can be used as a boot option too. Currently we have below setting: -default, BIOS default setting -powersave, highest power saving mode, enable all available ASPM state and clock power management -performance, highest performance, disable ASPM and clock power management By default, the 'default' policy is used currently. In my test, power difference between powersave mode and performance mode is about 1.3w in a system with 3 PCIE links. Note: some devices might not work well with aspm, either because chipset issue or device issue. The patch provide API (pci_disable_link_state), driver can disable ASPM for specific device. Signed-off-by: NShaohua Li <shaohua.li@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Gary Hade 提交于
The PCI bus names included in /proc/iomem and /proc/ioports are of the form 'PCI Bus #XX' where XX is the bus number. This patch changes the naming to 'PCI Bus XXXX:YY' where XXXX is the domain number and YY is the bus number. For example, PCI bus 14 in domain 0 will show as 'PCI Bus 0000:14' instead of 'PCI Bus #14'. This change makes the naming consistent with other architectures such as ia64 where multiple PCI domain support has been around longer. Signed-off-by: NGary Hade <garyhade@us.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Adrian Bunk 提交于
#if 0 the no longer used pci_cleanup_aer_correct_error_status(). Signed-off-by: NAdrian Bunk <bunk@kernel.org> Cc: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Yinghai Lu 提交于
[PATCH] pcie AER: don't check _OSC when acpi is disabled when acpi=off or pci=noacpi, get warning AER service couldn't init device 0000:00:0a.0:pcie01 - no _OSC support AER service couldn't init device 0000:00:0e.0:pcie01 - no _OSC support AER service couldn't init device 0000:00:0f.0:pcie01 - no _OSC support AER service couldn't init device 0000:80:0b.0:pcie01 - no _OSC support AER service couldn't init device 0000:80:0e.0:pcie01 - no _OSC support AER service couldn't init device 0000:80:0f.0:pcie01 - no _OSC support so don't check _OSC in aer_osc_setup Signed-off-by: NYinghai Lu <yinghai.lu@sun.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
This patch finally removes the global list of PCI devices. We are relying entirely on the list held in the driver core now, and do not need a separate "shadow" list as no one uses it. Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 James Bottomley 提交于
Remove the parisc usage of the global_list, as it's not needed anymore. Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
This lets us check if the device is really added to the driver core or not, which is what we need when walking some of the bus lists. The flag is there in anticipation of getting rid of the other PCI device list, which is what we used to check in this situation. Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
no_pci_devices() should use the driver core list of PCI devices, not our "separate" one. Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
This was marked incorrectly for some reason. Allow the ibmphp driver to be built even if PCI_LEGACY is not enabled. Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
This removes the depandancy of the cpcihp driver from the PCI_LEGACY config option by removing its usage of the pci_find_bus() function. Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: NScott Murray <scottm@somanetworks.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
This cleans up the search.c file, now using the pci list of devices that are created for the driver core, instead of relying on our separate list of devices. It's better to use the functions already created for this kind of thing, instead of rolling our own all the time. This work is done in anticipation of getting rid of that second list of pci devices all together. And it ends up saving code, always a nice benefit. This also removes one compiler warning for when CONFIG_PCI_LEGACY is enabled as we no longer internally use the deprecated functions anymore. Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
This removes the pci_get_device_reverse function as there should not be any need to walk pci devices backwards anymore. All users of this call are now gone from the tree, so it is safe to remove it. Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Greg Kroah-Hartman 提交于
No one is using this function anymore for quite some time, so remove it. Everyone calls pci_dev_present() instead anyway... Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Adrian Bunk 提交于
An unused function that bloated the kernel only when CONFIG_EMBEDDED was enabled... Signed-off-by: NAdrian Bunk <bunk@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 19 4月, 2008 7 次提交
-
-
由 James Bottomley 提交于
The kernel now panics reliably on boot if you have a SATAPI device connected. The problem was introduced by the libata merge trying to pull out all the SFF code into a separate module. Unfortunately, if you're a satapi device you usually need to call atapi_request_sense, which has a bare invocation of a SFF callback which is NULL on non-SFF HBAs. Fix this by making the call conditional. Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Boaz Harrosh 提交于
access the right scsi_in() and/or scsi_out() side of things. also for resid Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com> Reviewed-by: NPete Wyckoff <pw@osc.edu> Signed-off-by: NMike Christie <michaelc@cs.wisc.edu> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Boaz Harrosh 提交于
- prepare the additional bidi_read rlength header. - access the right scsi_in() and/or scsi_out() side of things. also for resid. - Handle BIDI underflow overflow from target Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com> Reviewed-by: NPete Wyckoff <pw@osc.edu> Signed-off-by: NMike Christie <michaelc@cs.wisc.edu> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Boaz Harrosh 提交于
Support for extended CDBs in iscsi. All we need is to check if command spills over 16 bytes then allocate an iscsi-extended-header for the leftovers. Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com> Reviewed-by: NPete Wyckoff <pw@osc.edu> Signed-off-by: NMike Christie <michaelc@cs.wisc.edu> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Christof Schmitt 提交于
In the case the unit is blocked, zfcp_unit_get has not been called yet, so the error handling path should not call zfcp_unit_put. Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: NMartin Peschke <mp3@de.ibm.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Christof Schmitt 提交于
The testcase # chchp -v 0 0.da && sleep 59 && chchp -v 1 0.da results in this deadlock situation: STACK TRACE FOR TASK: 0x7e9a2048 (zfcperp0.0.c613) 0 schedule+816 [0x356b3c] 1 schedule_timeout+172 [0x357340] 2 wait_for_common+192 [0x3565fc] 3 flush_cpu_workqueue+116 [0x52af0] 4 flush_workqueue+116 [0x533b8] 5 fc_remote_port_add+64 [0x1c83ec] 6 zfcp_erp_thread+4534 [0x26585a] 7 kernel_thread_starter+6 [0x195d2] STACK TRACE FOR TASK: 0x7f8ec048 (fc_wq_0) 0 schedule+816 [0x356b3c] 1 zfcp_erp_wait+104 [0x264568] 2 zfcp_scsi_slave_destroy+64 [0x261b24] 3 __scsi_remove_device+154 [0x1c24ba] 4 scsi_remove_device+62 [0x1c2512] 5 __scsi_remove_target+198 [0x1c25ea] 6 __remove_child+58 [0x1c26d6] 7 device_for_each_child+66 [0x1ab566] 8 scsi_remove_target+98 [0x1c268a] 9 run_workqueue+200 [0x5272c] 10 worker_thread+146 [0x52882] 11 kthread+140 [0x58360] 12 kernel_thread_starter+6 [0x195d2] Remove the zfcp_erp_wait call that is not required here to prevent the deadlock situation. Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: NMartin Peschke <mp3@de.ibm.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Martin Peschke 提交于
drivers/s390/scsi/zfcp_aux.c: In function ‘zfcp_fsf_incoming_els_rscn’: drivers/s390/scsi/zfcp_aux.c:1379: warning: cast from pointer to integer of different size drivers/s390/scsi/zfcp_aux.c: In function ‘zfcp_fsf_incoming_els_plogi’: drivers/s390/scsi/zfcp_aux.c:1432: warning: cast from pointer to integer of different size drivers/s390/scsi/zfcp_aux.c: In function ‘zfcp_fsf_incoming_els_logo’: drivers/s390/scsi/zfcp_aux.c:1457: warning: cast from pointer to integer of different size .. Just passing pointers rids us of these warnings and improves readability. Signed-off-by: NMartin Peschke <mp3@de.ibm.com> Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
- 18 4月, 2008 14 次提交
-
-
由 Adrian Bunk 提交于
This patch contains the following cleanups: - #if 0 the following unused structs: - fw-transaction.c:fw_low_memory_region - fw-transaction.c:fw_private_region - fw-transaction.c:fw_csr_region - fw-transaction.c:fw_unit_space_region - remove the following unused EXPORT_SYMBOL's: - fw-card.c:fw_core_add_descriptor - fw-card.c:fw_core_remove_descriptor - fw-iso.c:fw_iso_context_create - fw-iso.c:fw_iso_context_destroy - fw-iso.c:fw_iso_context_start - fw-iso.c:fw_iso_context_queue - fw-iso.c:fw_iso_context_stop Signed-off-by: NAdrian Bunk <bunk@kernel.org> Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
Fix: The fact that nodes had different gap counts would be overlooked if the bus manager code would pick gap count 63 because of beta repeaters or because of very large hop counts. In this case, the bus manager code would miss that it actually has to send the PHY config packet with gap count 63. Related trivial changes: Use bool for an int used as bool, touch up some comments. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
We now exit fw_send_phy_config /after/ the PHY config packet has been transmitted, instead of before. A subsequent fw_core_initiate_bus_reset will therefore not overlap with the transmission. This is meant to make the send PHY config packet + reset bus routine more deterministic. Fixes bus reset loop and eventual panic with - VIA VT6307 + IOGEAR hub + Unibrain Fire-i camera http://bugzilla.kernel.org/show_bug.cgi?id=10128 - JMicron card Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NJarod Wilson <jwilson@redhat.com>
-
由 Stefan Richter 提交于
request_generation is internal to fw-ohci and unneeded in fw_card. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Jarod Wilson 提交于
for code efficiency. Signed-off-by: NJarod Wilson <jwilson@redhat.com> Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Jarod Wilson 提交于
Trivial change to replace more meaningless (to the untrained eye) hex values with defined CSR constants. Signed-off-by: NJarod Wilson <jwilson@redhat.com> Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
When a device changes its configuration ROM, it announces this with a bus reset. firewire-core has to check which node initiated a bus reset and whether any unit directories went away or were added on this node. Tested with an IOI FWB-IDE01AB which has its link-on bit set if bus power is available but does not respond to ROM read requests if self power is off. This implements - recognition of the units if self power is switched on after fw-core gave up the initial attempt to read the config ROM, - shutdown of the units when self power is switched off. Also tested with a second PC running Linux/ieee1394. When the eth1394 driver is inserted and removed on that node, fw-core now notices the addition and removal of the IPv4 unit on the ieee1394 node. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
read_bus_info_block() is repeatedly called by workqueue jobs. These will step on each others toes eventually if there are multiple workqueue threads, and we end up with corrupt config ROM images. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Stefan Richter 提交于
Unlike the ohci1394 driver, fw-ohci uses the selfIDGeneration field of bus reset packets to determine the generation of incoming requests as per OHCI 1.1 clause 8.4.2.3. This is more precise --- provided that the controller inserts the correct generation. Texas Instruments chips often don't. This prevented the transmission of response packets, which for example broke AV/C transactions as used when communicating with miniDV cameras and any other AV/C devices. There is apparently no way to detect and adjust incorrect generations. Therefore we ignore the generation of bus reset packets from TI chips and use the generation of the self ID buffer instead. Alas this is received at a slightly wrong time. In rare cases, this could cause us to not respond to legitimate requests or to respond to expired requests. (The latter is less likely because the bus reset packet AR event is typically handled before the self ID complete event.) Bug reported by Mladen Kuntner, who was extraordinarily patient while dealing with the driver maintainers. Fix confirmed to be required and effective for TSB82AA2 and a TSB43AB22 or TSB43AB22A. https://bugzilla.redhat.com/show_bug.cgi?id=243081Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NJarod Wilson <jwilson@redhat.com>
-
由 Stefan Richter 提交于
Extend the logging of "AR evt_bus_reset, link internal" to "AR evt_bus_reset, generation ${selfIDGeneration}". That way we can check whether this generation matches the one seen in self ID complete event logging. See OHCI 1.1 clause 8.4.2.3. Also extend logging of "firewire_ohci: * selfIDs, generation *" by "local node ID ffc*" in self ID logging to make the local node in AT/AR event logs more obvious. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NJarod Wilson <jwilson@redhat.com>
-
由 Stefan Richter 提交于
Add a debug option to watch bus reset interrupt events. Half of this patch is taken from Jarod Wilson's first version of the JMicron fix. BusReset interrupts are only generated if the respective module parameter flag was set before the controller is being initialized. Else we keep this event masked to reduce IRQ load in normal operation and to avoid potential problems with buggy chips. Note, this is unlike the other IRQ events whose logging can be enabled any time after chip initialization. This and the influence on what interrupts the chip generates is why I added an extra flag for it. Also, reorder the debug parameter flags according to their perceived usefulness. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NJarod Wilson <jwilson@redhat.com>
-
由 Jarod Wilson 提交于
I finally tracked down the issues with this JMicron PCI-e card in my possession to a failure to comply with section 7.2.3.2 of the OHCI 1.1 specification (thanks to Kristian for the pointer to illustrate that it is indeed a flaw in this card, not the driver). The controller should simply flush the packets we've appended to its AT queue if a bus reset occurs before they've been transmitted and we'll try again, but something goes wrong and the controller winds up hung. However, we can avoid the problem by simply checking if the IntEvent.busReset register had been set before we try appending to the AT context. When busReset is set, the AT context is completely halted until busReset is cleared, so there's no point in appending AT packets until the register is cleared. So at_context_queue_packet() now checks for busReset being set, and bails with an RCODE_GENERATION packet ack, which results in us trying to append the packet again after recognizing the fact there has been a bus reset, and clearing busReset. Signed-off-by: NJarod Wilson <jwilson@redhat.com> Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-
由 Jarod Wilson 提交于
While trying to debug this piece of crap JMicron PCI-e controller in my possession, one thought was that perhaps I was encountering register access failures. I'm not, but logging them would be good, so we can see if they are a real problem we should be taking into account anywhere in the code. Signed-off-by: NJarod Wilson <jwilson@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (added list contact)
-
由 Jarod Wilson 提交于
I've now witnessed multiple occasions where one of my controllers (a very poorly working JMicron PCIe card) fails to get its registers properly set up in ohci_enable(), apparently due to an occasionally very slow to initiate SClk. The easy fix for this problem is to add a tiny while loop to try again a time or three after initially enabling LPS before we move on (or give up). Of course, the card still isn't fully functional yet, but this gets it at least one tiny step closer... Signed-off-by: NJarod Wilson <jwilson@redhat.com> Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
-