linux-kernel - Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b1b409e0-9243-83a6-8379-50f933c97477@gmail.com>
Date:   Fri, 20 Jan 2017 20:49:26 +1300
From:   Michael Schmitz <schmitzmic@...il.com>
To:     Finn Thain <fthain@...egraphics.com.au>
Cc:     Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Tejun Heo <tj@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-ide@...r.kernel.org,
        Linux/m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Development <linux-kernel@...r.kernel.org>,
        Andreas Schwab <schwab@...ux-m68k.org>
Subject: Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

Hi Finn,

Am 15.01.2017 um 17:42 schrieb Finn Thain:

>> No, we can't check either FDC or SCSI interrupts (or indeed any chip 
>> registers) without touching the ST-DMA. The moment we select a FDC or 
>> SCSI register for read, DMA is terminated no questions asked.
>>
> 
> Perhaps we can convert DMA operations to PDMA (by polling with local irqs 
> disabled) and avoid the whole problem of interrupt handlers executing 
> during DMA transfers. The docs suggest that it is doable.
> 
> "Poll or service the Disk Driver Controller interrupt on the MK68901 MFP 
> General Purpose I/O Register to detect the completion of a WD1772 FDC 
> command. Do not poll the FDC Busy or DMA Sector Count Zero status bits." 
> -- ST HW Spec, p. 36.
> http://dev-docs.atariforge.org/files/ST_HW_Spec_1-7-1986.pdf

The MFP interrupt in question is the same as the one used by IDE
(wired-OR of IDE, FDC and SCSI), so we would still have to figure out
where the interrupt originated. Polling instead of taking the interrupt
does not change that fundamental problem (unless I'm missing something).

> 
> On page 18 there is an algorithm for floppy writes which is interesting.

That one (and the ACSI algorithm which would apply to SCSI for Falcon)
does suggest it won't be possible to peek at the sector count register
to detect end of DMA. The addendum (note 841017G) makes it clear that a
write to the DMA mode register is required to look at the status
register error bit (which might terminate DMA).

Maybe the DMA address register can be used to check for DMA completion
... it's used to check for residual or lost bytes anyway so that appears
to work. And the FDC driver does use the same strategy to check if
enough track data have been read.

Leaves the case where DMA hasn't completed but may have been aborted by
a NCR5380 interrupt. I suppose we can detect that by checking for any
change in the DMA address while repeatedly reading the DMA address
register. No change means the DMA has got stuck. Not exactly pretty but
all I can come up with.

> 
> I suspect that we will need to keep the FDC idle during SCSI transfers 
> (and vice versa) much as the present stdma.c lock does.
> 
> "The interrupt outputs of the internal floppy disk controller and the 
> external ACSI DMA port are logically OR'ed. The pin of the MFP GPIP will 
> read as a '0' if either the FDC or a selected ACSI device controller is 
> asserting its interrupt request."
> -- ACSI/DMA Integration Guide, p.16.
> http://dev-docs.atariforge.org/files/ACSI_DMA_Guide_6-28-1991.pdf

On Falcon, the IDE interrupt is also OR'ed to the above two interrupt
lines, hence the need for including IDE in the locking scheme there.

> 
> Polling the logically OR'ed interrupt sources to detect end-of-DMA will 
> not be reliable unless we disable those sources that aren't relevant. 
> Otherwise we access the DMA registers too early (which IIUC would kill the 
> transfer). I'm afraid we shall have to expect that a few transfers will be 
> interrupted by other devices in this way, and carefully check for this. 
> 
> For example, the 5380 SCSI bus reset interrupt is not maskable, which 
> could affect FDC transfers. If this terminated the polling for DMA 
> completion, the FDC driver then has to access the FDC registers and 
> confirm that the transfer was not terminated early.
> 

We'll have to make sure FDC and SCSI don't clash in their DMA and
interrupt use.

Cheers,

	Michael