linux-kernel - Re: [PATCH 13/15] ide: fix UDMA/MWDMA/SWDMA masks

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]

Date:	Thu, 25 Jan 2007 18:40:23 +0300
From:	Sergei Shtylyov <sshtylyov@...mvista.com>
To:	Alan <alan@...rguk.ukuu.org.uk>
Cc:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 13/15] ide: fix UDMA/MWDMA/SWDMA masks

Hello.

Sergei Shtylyov wrote:

>> Not a suprise to be honest. I fixed some of the ALi stuff when I did it
>> and I think that was pushed back into drivers/ide. The CMD64x hasn't had
>> much love really.

>    Another buglet found by random glancing at this driver:

> /**
>  *      cmd648_dma_stop -       DMA stop callback
>  *      @qc: Command in progress
>  *
>  *      DMA has completed.
>  */

> static void cmd648_bmdma_stop(struct ata_queued_cmd *qc)
> {
>         struct ata_port *ap = qc->ap;
>         struct pci_dev *pdev = to_pci_dev(ap->host->dev);
>         u8 dma_intr;
>         int dma_reg = ap->port_no ? ARTTIM23_INTR_CH1 : CFR_INTR_CH0;
>         int dma_mask = ap->port_no ? ARTTIM2 : CFR;
> 
>         ata_bmdma_stop(qc);
> 
>         pci_read_config_byte(pdev, dma_reg, &dma_intr);
>         pci_write_config_byte(pdev, dma_reg, dma_intr | dma_mask);
> }

>    dma_reg and dma_mask initializers must have been swapped since 
> ARTTIM2 and CFR are regster names.  So, the code reads/writes 
> semi-random regs...

    BTW, on PCI0646U2 and later chips, the interrupt status (it's not really 
DMA interrupt status but a latched INTRQ signal not "coupled" with DMA logic, 
according to the datasheets) can be read from MRDMODE reg. which is accessible 
in I/O space at BMIDE base + 1 which is certainly faster.  That's what 
drivers/ide/cmd64x.c is doing in its test_dma_irq() method (however, it's 
doign this on PCI0643 and early revs of PCI0646 which don't have these bits).
The driver's dma_end() method is acting really strange: it checks if the cjip 
is PCI-648/9 and reads the PCI config space to clear those interrupt bits 
while these chips have them in I/O mapped MRDMODE; OTOH, it ignores these bits 
on earlier chips which have them in oonfig. space only (CFR/ARTTIM23 regs)... 
go figure.  I'm going to clean this up but don't heve the h/w handy... :-/

>> Wouldn't mind the older 64x (not 640) data sheets if they are sharable.

>    Sent what I had on this machine.  Will looks for newer revision of 
> PCJ0646U2 spec elsewhere...

    Sent rev. 1.3... Hopefully gkernel.sourceforge.net/specs/ will be updated.

MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/