linux-kernel - Re: [PATCH] libata: Add MMIO support to pata

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:	Fri, 15 Feb 2008 23:56:47 +0000
From:	Tim Ellis <tim@...dg.com>
To:	benh@...nel.crashing.org
Cc:	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, jeff@...zik.org
Subject: Re: [PATCH] libata: Add MMIO support to pata_sil680


On 15 Feb 2008, at 21:45, Benjamin Herrenschmidt wrote:

>
> On Fri, 2008-02-15 at 15:53 +0000, Alan Cox wrote:
>>>> That's strange though. Somebody with knowledge of that HW (or  
>>>> specs) who
>>>> can spot something ? Could it be an issue with timing ?
>>>>
>>>> I don't have HW access to this machine. If somebody could send  
>>>> one to me
>>>> I could do more investigation.
>>>
>>> Ben, would an ssh access to such a machine and to a terminal server
>>> suffice?
>>
>> It says clearly in the code where to start. See the FIXME notes in  
>> both
>> libata-sff and libata-core about MMIO. Neither the DMA transfer  
>> start or
>> the probe SRST sequence are correct with MMIO posting and this hasn't
>> been fixed as I pointed out was needed when I originally NAKked the
>> change.
>>
>> Without those being fixed (especially SRST) on any device with  
>> heavy PCI
>> posting of mmio your controller *wont work*.
>
> The dbdma start is mostly harmless (things don't get posted for -that-
> long), though I suppose it's worth fixing. Would reading back dmactl  
> do
> in that case or do you foresee any kind of side effect ? (Maybe only
> doing it for MMIO ?)
>
> As for SRST, I'm not totally confident how safe it is to read back
> there while doing the reset sequence, so I'm tempted to really only
> do it for MMIO and use altstat rather than ctl/stat (the later tends
> to have side effects which we don't want here).
>
> What do you think ?
>
> The main problem from here is that I don't know whether we are using
> MMIO or PIO from libata-core. Maybe I can add a host flag indicate
> that such flushing is needed ?
>
> In the meantime, Guennadi, can you check if that patch helps for you
> (to see if that is indeed the problem):
>
>
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 004dae4..1451a52 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -3461,10 +3461,13 @@ static int ata_bus_softreset(struct ata_port  
> *ap, unsigned int devmask,
>
> 	/* software reset.  causes dev0 to be selected */
> 	iowrite8(ap->ctl, ioaddr->ctl_addr);
> +	ioread16(ioaddr->nsect_addr);
> 	udelay(20);	/* FIXME: flush */
> 	iowrite8(ap->ctl | ATA_SRST, ioaddr->ctl_addr);
> +	ioread16(ioaddr->nsect_addr);
> 	udelay(20);	/* FIXME: flush */
> 	iowrite8(ap->ctl, ioaddr->ctl_addr);
> +	ioread16(ioaddr->nsect_addr);
>
> 	/* wait a while before checking status */
> 	ata_wait_after_reset(ap, deadline);
> diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
> index 60cd4b1..81d5828 100644
> --- a/drivers/ata/libata-sff.c
> +++ b/drivers/ata/libata-sff.c
> @@ -273,6 +273,7 @@ void ata_bmdma_start(struct ata_queued_cmd *qc)
> 	 * FIXME: The posting of this write means I/O starts are
> 	 * unneccessarily delayed for MMIO
> 	 */
> +	ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
> }
>
> /**
>
> Cheers,
> Ben.


Unfortunately this patch appears to give same result as in the  
original post. Guennadi and I are looking into arranging access to a  
device. Thanks!

<7>pata_sil680 0000:00:0c.0: version 0.4.8
<6>sil680: 133MHz clock.
<6>scsi0 : pata_sil680
<6>scsi1 : pata_sil680
<6>ata1: PATA max UDMA/133 irq 18
<6>ata2: PATA max UDMA/133 irq 18

Tim
--
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/