- 15 9月, 2016 3 次提交
-
-
由 Bjorn Helgaas 提交于
Long ago, we updated a "switch_save" field based on the latch status. But switch_save was unused, and ed6cbcf2 ("[PATCH] pciehp: miscellaneous cleanups") removed it. We no longer use the latch status, so remove calls to pciehp_get_latch_status(). No functional change intended. Tested-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Bjorn Helgaas 提交于
Print slot name consistently as "Slot(%s)". I don't know whether that's ideal, but we can at least do it the same way all the time. No functional change intended. Tested-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Mayurkumar Patel 提交于
Previously we read Slot Status when handling a surprise event. But Slot Status might have changed since we identified the event, and the event_type already tells us whether to enable or disable the slot, so there's no need to read it again. Remove handle_surprise_event() and queue the power work directly. [bhelgaas: changelog] Tested-by: NLukas Wunner <lukas@wunner.de> Signed-off-by: NMayurkumar Patel <mayurkumar.patel@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NRajat Jain <rajatxjain@gmail.com>
-
- 23 8月, 2016 1 次提交
-
-
由 Keith Busch 提交于
Clear the LED attention status after a successful device add. It is possible the attention LED was on from a previous power fault or link failure, and a subsequent successful device insert insertion should clear it. Signed-off-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 26 11月, 2015 1 次提交
-
-
由 Guenter Roeck 提交于
When called from pciehp_sysfs_disable_slot(), the call to pciehp_disable_slot() was not protected by the hotplug mutex. Hold slot->hotplug_lock while calling pciehp_disable_slot(). Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NRajat Jain <rajatxjain@gmail.com>
-
- 22 10月, 2015 1 次提交
-
-
由 Guenter Roeck 提交于
Up to now, work items to be queued to be handled by pciehp_power_thread() are allocated using kmalloc() in three different locations. If not needed, kfree() is called to free the allocated data. Introduce a separate function to allocate the work item and queue it, and call it only if needed. This reduces code duplication and avoids having to free memory if the work item does not need to get executed. [bhelgaas: tweak "no memory" message, make pciehp_queue_power_work() static] Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 19 6月, 2015 3 次提交
-
-
由 Bjorn Helgaas 提交于
The pciehp_handle_*() functions (pciehp_handle_attention_button(), etc.) only contain a line or two of useful code, so it's clumsy to put them in separate functions. All they so is add an event to a work queue, and it's clearer to see that directly in the ISR. Inline them directly into pcie_isr(). No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NRajat Jain <rajatja@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
Rename queue_interrupt_event() to pciehp_queue_interrupt_event() so we can make it extern and call it from pcie_isr(). No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NRajat Jain <rajatja@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
Nobody looks at the return value from queue_interrupt_event(), so errors were silently ignored. Convert it to a "void" function and note the error in the dmesg log. No functional change except the new message. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NRajat Jain <rajatja@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
- 18 6月, 2015 1 次提交
-
-
由 Bjorn Helgaas 提交于
The pciehp debug logging is overly verbose and often redundant. Almost all of the information printed by dbg_ctrl() is also printed by the normal PCI core enumeration code and by pcie_init(). Remove the redundant debug info. When claiming a pciehp bridge, we print the slot characteristics, e.g., Slot #6 AttnBtn- AttnInd- PwrInd- PwrCtrl- MRL- Interlock- NoCompl+ LLActRep+ Add the Hot-Plug Capable and Hot-Plug Surprise bits to this information, and print it all in the same order as lspci does. No functional change except the message text changes. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NRajat Jain <rajatja@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
- 22 1月, 2015 1 次提交
-
-
由 Bjorn Helgaas 提交于
The PCIe spec (r3.0, sec 7.8.9) says Hot-Plug Surprise indicates support for surprise *removal*, but pciehp checked this to determine if it should handle presence detect interrupts for device *addition*. Allow surprise device addition even if the slot doesn't advertise support for surprise removal. Keith has a platform with slots for front-loading SFF devices. The slots do not have attention buttons and do not support surprise removal, but they do have presence detect. In that case, we still want to use presence detect for device addition. Keith's original patch handled surprise insertions only if Hot-Plug Capable is set. I think that test is superfluous because pciehp only claims slots that advertise Hot-Plug Capable (see get_port_device_capability()). Link: http://lkml.kernel.org/r/1419275223-14602-1-git-send-email-keith.busch@intel.comBased-on-patch-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRajat Jain <rajatxjain@gmail.com>
-
- 11 6月, 2014 2 次提交
-
-
由 Ryan Desfosses 提交于
Merge quoted strings that are broken across lines into a single entity. The compiler merges them anyway, but checkpatch complains about it, and merging them makes it easier to grep for strings. No functional change. [bhelgaas: changelog, do the same for everything under drivers/pci] Signed-off-by: NRyan Desfosses <ryan@desfo.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Ryan Desfosses 提交于
Fix various whitespace errors. No functional change. [bhelgaas: fix other similar problems] Signed-off-by: NRyan Desfosses <ryan@desfo.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 20 2月, 2014 2 次提交
-
-
由 Bjorn Helgaas 提交于
Minor whitespace cleanup; no functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Rajat Jain 提交于
In case a card is physically yanked out, it should immediately be removed, regardless of the "surprise" capability bit. Thus: - Always handle the physical removal - regardless of the "surprise" bit. - Don't use "surprise" capability when making decisions about enabling presence detect notifications. - Reword the comments to indicate the intent. Signed-off-by: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 15 2月, 2014 1 次提交
-
-
由 Yijing Wang 提交于
If we found device already exists during hot add device, we should leave it, not turn the slot off. Signed-off-by: NYijing Wang <wangyijing@huawei.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 12 2月, 2014 3 次提交
-
-
由 Rajat Jain 提交于
Today it is there is no protection around pciehp_enable_slot() and pciehp_disable_slot() to ensure that they complete before another hot-plug operation can be done on that particular slot. This patch introduces the slot->hotplug_lock to ensure that any hotplug operations (add / remove) complete before another hotplug event can begin processing on that particular slot. Signed-off-by: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Rajat Jain 提交于
Today, this is how all the hotplug and unplug events work: Hotplug / Removal needs to be done => Set slot->state (protected by slot->lock) to either POWERON_STATE (for enabling) or POWEROFF_STATE (for disabling). => Submit the work item for pciehp_power_thread() to slot->wq. Problem: There is a problem if the hotplug events can happen fast enough that they do not give SW enough time to add or remove the new devices. => Assume: Event for unplug comes (e.g. surprise removal). But before the pciehp_power_thread() work item was executed, the card was replaced by another card, causing surprise hotplug event. => What goes wrong: => The hot-removal event sets slot->state to POWEROFF_STATE, and schedules the pciehp_power_thread(). => The hot-add event sets slot->state to POWERON_STATE, and schedules the pciehp_power_thread(). => Now the pciehp_power_thread() is scheduled twice, and on both occasions it will find POWERON_STATE and will try to add the devices on the slot, and will fail complaining that the devices already exist. => Why this is a problem: If the device was replaced between the hot removal and hot-add, then we should unload the old driver and reload the new one. This does not happen today. The kernel or the driver is not even aware that the device was replaced. The problem is that the pciehp_power_thread() only looks at the slot->state which would only contain the *latest* state - not the actual event (add / remove) that was the intent of the IRQ handler who submitted the work. What this patch does: => Hotplug events pass on an actual request (for addition or removal) to pciehp_power_thread() which is local to that work item submission. => pciehp_power_thread() does not need to look at slote->state and hence no locks needed in that. => Essentially this results in all the hotplug and unplug events "replayed" by pciehp_power_thread(). Signed-off-by: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Rajat Jain 提交于
It does not make much sense to refuse to disable a slot if an adapter is not present or the latch is open. If an adapter is not present, it provides an even better reason to disable the device slot. This is specially a problem for link state hot-plug, because some ports use in band mechanism for presence detection. Thus when link goes down, presence detect also goes down. We _want_ that the removal should take place in such case. Thus remove the checks for adapter and latch in pciehp_disable_slot() Signed-off-by: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 11 2月, 2014 1 次提交
-
-
由 Rajat Jain 提交于
A lot of systems do not have the fancy buttons and LEDs, and instead want to rely only on the Link state change events to drive the hotplug and removal state machinery. (http://www.spinics.net/lists/hotplug/msg05802.html) This patch adds support for that functionality. Here are the details about the patch itself: * Define and use interrupt events for linkup / linkdown. * Make the pcie_isr() also look at link events, and direct control to corresponding (new) link state change handler function. * Introduce the functions to handle link-up and link-down events and queue the add / removal work in the slot->wq to be processed by pciehp_power_thread() As a side note, this patch also fixes the bug https://bugzilla.kernel.org/show_bug.cgi?id=65521 "pciehp ignores Data Link Layer State Changed bit." Signed-off-by: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 16 12月, 2013 2 次提交
-
-
由 Bjorn Helgaas 提交于
Previously, the caller checked ATTN_LED() or PWR_LED() to see whether the slot has indicators before setting the indicator state. That clutters the caller unnecessarily, so this moves the test inside the callees. The test may not even be necessary; per spec it should be harmless to try to turn on a non-existent LED. But checking first does avoid unnecessary hotplug commands. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
These functions: pcie_enable_notification() pciehp_power_off_slot() pciehp_get_power_status() pciehp_get_attention_status() pciehp_set_attention_status() pciehp_get_latch_status() pciehp_get_adapter_status() pcie_write_cmd() now always return success, so this patch makes them void and drops the error-checking code in their callers. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 13 1月, 2013 1 次提交
-
-
由 Yijing Wang 提交于
When we have a hotplug-capable PCIe port with a second hotplug-capable PCIe port below it, removing the device below the upstream port causes a deadlock. The deadlock happens because we use the pciehp_wq workqueue to run pciehp_power_thread(), which uses pciehp_disable_slot() to remove devices below the upstream port. When we remove the downstream PCIe port, we call pciehp_remove(), the pciehp driver's .remove() method. That calls flush_workqueue(pciehp_wq), which deadlocks because the pciehp_power_thread() work item is still running. This patch avoids the deadlock by creating a workqueue for every PCIe port and removing the single shared workqueue. Here's the call path that leads to the deadlock: pciehp_queue_pushbutton_work queue_work(pciehp_wq) # queue pciehp_power_thread ... pciehp_power_thread pciehp_disable_slot remove_board pciehp_unconfigure_device pci_stop_and_remove_bus_device ... pciehp_remove # pciehp driver .remove method pciehp_release_ctrl pcie_cleanup_slot flush_workqueue(pciehp_wq) This is fairly urgent because it can be caused by simply unplugging a Thunderbolt adapter, as reported by Daniel below. [bhelgaas: changelog] Reference: http://lkml.kernel.org/r/CAMVG2ssiRgcTD1bej2tkUUfsWmpL5eNtPcNif9va2-Gzb2u8nQ@mail.gmail.comReported-and-tested-by: NDaniel J Blueman <daniel@quora.org> Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NYijing Wang <wangyijing@huawei.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org
-
- 07 1月, 2012 1 次提交
-
-
由 Kenji Kaneshige 提交于
Use non-ordered workqueue for attention button events. Attention button events on each slot can be handled asynchronously. So we should use non-ordered workqueue. This patch also removes ordered workqueue in pciehp as a result. Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 06 12月, 2011 1 次提交
-
-
由 Kenji Kaneshige 提交于
Use non-ordered workqueue for attention button events. Attention button events on each slot can be handled asynchronously. So we should use non-ordered workqueue. This patch also removes ordered workqueue in pciehp as a result. Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 12 11月, 2011 1 次提交
-
-
由 Kenji Kaneshige 提交于
We need to wait for 1000 ms after Data Link Layer Link Active (DLLLA) bit reads 1b before sending configuration request. Currently pciehp does this wait after checking Link Training (LT) bit. But we need it before checking LT bit because LT is still set even after DLLLA bit is set on some platforms. Acked-by: NYinghai Lu <yinghai@kernel.org> Tested-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 23 7月, 2011 1 次提交
-
-
由 Kenji Kaneshige 提交于
Naoki Yanagimoto reported that configuration read on some hot-added PCIe device returns invalid value. This patch fixes this problem. According to the PCIe spec, software must wait for at least 1 second to judge if the hot-added device is broken after Data Link Layer State Changed Event. This patch changes pciehp driver to wait for 1 second after the Data Link Layer State Changed Event is detected before initiating a configuration access instead of 100 ms. Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Tested-by: NNaoki Yanagimoto <yanagimoto@np.css.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 18 10月, 2010 1 次提交
-
-
由 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>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 23 2月, 2010 1 次提交
-
-
由 Jiri Slaby 提交于
Stanse found a cut&pasted memory leak in pciehp_queue_pushbutton_work and shpchp_queue_pushbutton_work. info is not freed/assigned on all paths. Fix that. Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJiri Slaby <jslaby@suse.cz> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 25 11月, 2009 1 次提交
-
-
由 Kenji Kaneshige 提交于
Enabling power fault detected event notification in current pciehp might cause power fault interrupt storm on some machines. On those machines. On those machines, power fault detected bit in the slot status register was set again immediately when it is cleared in the interrupt service routine, and next power fault detected interrupt was notified again. Therefore, disable power fault detected event notification for now. This patch also removes unnecessary handling for power fault cleared event because this event is not supported by PCIe spec. Tested-by: NJens Axboe <jens.axboe@oracle.com> Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 05 11月, 2009 1 次提交
-
-
由 Kenji Kaneshige 提交于
Current pciehp returns successfully on read/write failure with dummy state values. It should return error instead. With this patch, pciehp no longer uses hotplug_slot_info data structure. So this also removes hotplug_slot_info related code. But note that it still allocates hotplug_slot_info because it is required by pci hotplug core. Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 18 9月, 2009 8 次提交
-
-
由 Kenji Kaneshige 提交于
Remove (almost) unused error message definitions. Acked-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Kenji Kaneshige 提交于
The struct hpc_ops seems a set of hooks to controller specific routines. But, it is meaningless because no hotplug controller driver follows this framework. Acked-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Kenji Kaneshige 提交于
Since we have a pointer to pcie_device in struct controller, we don't need a pointer to pci_dev. Acked-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Kenji Kaneshige 提交于
The crit_sect mutex defined in struct controller is to serialize hot-plug operations against multiple slots under the same bus. But, since PCIe doesnstream port has only one slot at most, it is meaningless and we don't need it. Acked-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Kenji Kaneshige 提交于
Since the device number of the hot-slot under the PCIe downstream port is always 0, the slot_device_offset field in the slot is meaningless and we don't need it. Acked-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Kenji Kaneshige 提交于
The hp_slot field is to identify the slot under the same controller. But, since PCIe downstream port has only one slot at most, it is meaningless and we don't need it. Acked-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Kenji Kaneshige 提交于
The device field in the struct slot is not necessary because it is always 0 in pciehp driver. Acked-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Kenji Kaneshige 提交于
The bus field in struct slot is not necessary. Acked-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-