| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
This space does not require DMA syncing. It reduces lock scope of the DMA
scratch space. It allows whole DMA scratch space to be used to I/O, so now
we can fetch up to ~1000 ports from SNS.
Due to the last fact, increase maximal number of ports from 256 to 1024.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is even more important since it involves more network operations and
more prone to delays and timeouts.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before this change virtual ports control IOCBs were executed synchronously
via Execute IOCB mailbox command. It required exclusive use of scratch
space of driver and mailbox registers of the hardware. Because of that
shared resources use this code could not really sleep, having to spin for
completion, blocking any other operation.
This change introduces new asynchronous design, sending the IOCBs directly
on request queue and gracefully waiting for their return on response queue.
Returned IOCBs are identified with unified handle space from r292725.
|
| |
|
|
|
|
| |
I am not sure why this was split long ago, but I see no reason for it.
At this point this unification just slightly reduces memory usage, but
as next step I plan to reuse shared handle space for other IOCB types.
|
| |
|
|
|
| |
Previously it was done only on full chip reinit, that caused old ports
resurrect in case of virtual port reenabling.
|
| | |
|
| | |
|
| |
|
|
| |
Add initial support for 16Gbps FC QLogic chips.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
- Make scan aborted by event restart immediately and infinitely.
- Improve handling of some loop events from firmware.
- Remove loop down timer, adding its functionality to scanner thread.
- Some more unification and simplification.
|
| |
|
|
| |
New name better repsents its meaning for modern chips.
|
| | |
|
| |
|
|
|
| |
Now target mode works for all supported FC adapters except ancient 2100,
which is not tested.
|
| |
|
|
|
|
|
| |
Hacks to enable target mode there complicated code, while didn't really
work. And for outdated hardware fixing it is not really interesting.
Initiator mode tested with Qlogic 1080 adapter is still working fine.
|
| |
|
|
|
|
|
|
| |
Explicitly call SEND CHANGE REQUEST for pre-24xx chips in target mode.
While later firmware always registers for RSCN requests, older one does
it only in initiator mode. But in target mode there RSCN can be the only
way to detect gone intiator.
|
| |
|
|
| |
This makes port scanner fix absent port ID for added initiator.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I am not sure this value is really viable yet, but that is what chips
officially support in NPIV mode (in loop mode maximum is 125).
|
| |
|
|
|
|
|
| |
For those chips we are not receiving login events, adding initiators
based on ATIO requests. But there is no port ID in that structure, so
in fabric mode we have to explicitly fetch it from firmware to be able
to do normal scan after that.
|
| | |
|
| |
|
|
| |
Now with present 4K of scratch we can fetch up to 508 ports (16 more).
|
| |
|
|
|
|
| |
This change simplifies and unifies port adding/updating for loop and
fabric scanners. It also fixes problems with scanning restarts due to
concurrent port databases changes. It also fixes many cosmetic issues.
|
| |
|
|
|
| |
Except cosmetic changes this removes fabric ports from our port database.
It is always firmware duty to manage them, so driver don't need to worry.
|
| |
|
|
|
|
|
|
| |
Modern cards in most cases operate abstract port handles, that have no
any relation to real loop IDs. Leave loopid used only where it really
goes about local loop IDs.
While there, fix few more cases where LUNs were still printed in decimal.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
While there, simplify the wait logic.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Without docs I am not completely sure about this, but on my tests new
method works better then previous, at least with our latest firmware.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For the most of chips (except anscient ones) port handlers have no relation
to port IDs. In such situation old code scanning first 125 handlers was
quite naive. Instead of doing that, send to chip single request to get full
list of port handlers available on specific virtual port and scan only them.
Old code had problems with case of several virtual ports enabled, when port
handlers allocated from global address space could easily go above 125.
This change was successfully tested on 23xx, 24xx and 25xx chips in loop
mode with 4 virtual initiator ports, each seing 50 virtual target ports.
|
| |
|
|
|
| |
For some reason port handles should be allocated from HBA-global space,
while old code was not very specific, mixing per-HBA and per-VP logic.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Now on 24xx and above chips it is really possible to simulate several
virtual FC ports with single physical one. For example, it allows to
configure several targets in ctl.conf, assign each of them to separate
virtual port, and let user to control access to them with switch zoning.
I still doubt that all problems are solved there, but at now it passes
at least basic tests.
|
| | |
|
| | |
|
| | |
|
| | |
|
