mirror/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2024-11-21 19:46:16 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

scsi: NCR5380: Clean up indentation

Browse Source 
Tidy up a few indentation annoyances. No functional change.

Signed-off-by: Finn Thain <fthain@linux-m68k.org>
Link: https://lore.kernel.org/r/8541ea096fde9f8716b79e4f0707aed916a8c58d.1723001788.git.fthain@linux-m68k.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This commit is contained in:
Finn Thain 2024-08-07 13:36:28 +10:00 committed by Martin K. Petersen
parent c331df3d4a
commit a8ebca904f
3 changed files with 56 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
drivers/scsi/NCR5380.c
View File

@ -1319,15 +1319,17 @@ static void NCR5380_transfer_pio(struct Scsi_Host *instance,
dsprintk(NDEBUG_HANDSHAKE, instance, "REQ negated, handshake complete\n");
/*
* We have several special cases to consider during REQ/ACK handshaking :
* 1. We were in MSGOUT phase, and we are on the last byte of the
* message. ATN must be dropped as ACK is dropped.
* We have several special cases to consider during REQ/ACK
* handshaking:
*
* 2. We are in a MSGIN phase, and we are on the last byte of the
* 1. We were in MSGOUT phase, and we are on the last byte of
* the message. ATN must be dropped as ACK is dropped.
*
* 2. We are in MSGIN phase, and we are on the last byte of the
* message. We must exit with ACK asserted, so that the calling
* code may raise ATN before dropping ACK to reject the message.
*
* 3. ACK and ATN are clear and the target may proceed as normal.
* 3. ACK and ATN are clear & the target may proceed as normal.
*/
if (!(p == PHASE_MSGIN && c == 1)) {
if (p == PHASE_MSGOUT && c > 1)
@ -1568,29 +1570,31 @@ static int NCR5380_transfer_dma(struct Scsi_Host *instance,
* conditions. For non-scatter-gather operations, we can wait until REQ
* and ACK both go false, or until a phase mismatch occurs. Gather-sends
* are nastier, since the device will be expecting more data than we
* are prepared to send it, and REQ will remain asserted. On a 53C8[01] we
* could test Last Byte Sent to assure transfer (I imagine this is precisely
* why this signal was added to the newer chips) but on the older 538[01]
* this signal does not exist. The workaround for this lack is a watchdog;
* we bail out of the wait-loop after a modest amount of wait-time if
* the usual exit conditions are not met. Not a terribly clean or
* correct solution :-%
* are prepared to send it, and REQ will remain asserted. On a 53C8[01]
* we could test Last Byte Sent to assure transfer (I imagine this is
* precisely why this signal was added to the newer chips) but on the
* older 538[01] this signal does not exist. The workaround for this
* lack is a watchdog; we bail out of the wait-loop after a modest
* amount of wait-time if the usual exit conditions are not met.
* Not a terribly clean or correct solution :-%
*
* DMA receive is equally tricky due to a nasty characteristic of the NCR5380.
* If the chip is in DMA receive mode, it will respond to a target's
* REQ by latching the SCSI data into the INPUT DATA register and asserting
* ACK, even if it has _already_ been notified by the DMA controller that
* the current DMA transfer has completed! If the NCR5380 is then taken
* out of DMA mode, this already-acknowledged byte is lost. This is
* not a problem for "one DMA transfer per READ command", because
* the situation will never arise... either all of the data is DMA'ed
* properly, or the target switches to MESSAGE IN phase to signal a
* disconnection (either operation bringing the DMA to a clean halt).
* However, in order to handle scatter-receive, we must work around the
* problem. The chosen fix is to DMA fewer bytes, then check for the
* condition before taking the NCR5380 out of DMA mode. One or two extra
* bytes are transferred via PIO as necessary to fill out the original
* request.
* DMA receive is equally tricky due to a nasty characteristic of the
* NCR5380. If the chip is in DMA receive mode, it will respond to a
* target's REQ by latching the SCSI data into the INPUT DATA register
* and asserting ACK, even if it has _already_ been notified by the
* DMA controller that the current DMA transfer has completed! If the
* NCR5380 is then taken out of DMA mode, this already-acknowledged
* byte is lost.
*
* This is not a problem for "one DMA transfer per READ
* command", because the situation will never arise... either all of
* the data is DMA'ed properly, or the target switches to MESSAGE IN
* phase to signal a disconnection (either operation bringing the DMA
* to a clean halt). However, in order to handle scatter-receive, we
* must work around the problem. The chosen fix is to DMA fewer bytes,
* then check for the condition before taking the NCR5380 out of DMA
* mode. One or two extra bytes are transferred via PIO as necessary
* to fill out the original request.
*/
if ((hostdata->flags & FLAG_DMA_FIXUP) &&