linux-kernel - Re: Kernel Summit request for Discussion of future of ATA (libata) and IDE

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: <48990CA9.2060107@shaw.ca>
Date:	Tue, 05 Aug 2008 20:30:01 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Tejun Heo <htejun@...il.com>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-ide <linux-ide@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>
Subject: Re: Kernel Summit request for Discussion of future of ATA (libata)
 and IDE

Tejun Heo wrote:
> Robert Hancock wrote:
>> Here's my first cut at it. Compile tested only. This sets most controllers
>> to use 32-bit PIO except for those which could potentially be on a real ISA
>> or other 16-bit bus. It's a bit non-obvious what to do with some of the
>> drivers, so input is welcome.
>>
>> This implementation doesn't check the ata_id_has_dword_io at all, since it
>> would only make a difference on controllers where we don't really want to
>> use it anyway.
>>
>> It seems like regardless of whether we do 32-bit by default or not the 32-bit
>> data_xfer function should be added to libata core as we have several drivers
>> which duplicate the same code currently..
> 
> Great, just some minor nitpicks as I don't have much idea about 16 bit ones.
> 
>> +unsigned int ata_sff_data_xfer(struct ata_device *dev, unsigned char *buf,
>> +			       unsigned int buflen, int rw)
>> +{
>> +	struct ata_port *ap = dev->link->ap;
>> +	void __iomem *data_addr = ap->ioaddr.data_addr;
>> +	unsigned int words = buflen >> 2;
> 
> dwords maybe?
> 
>> +	unsigned int slop = buflen & 3;
>> +
>> +	/* Transfer multiple of 4 bytes */
>> +	if (rw == READ)
>> +		ioread32_rep(data_addr, buf, words);
>> +	else
>> +		iowrite32_rep(data_addr, buf, words);
>> +
>> +	/* Transfer trailing 1 byte, if any. */
> 
> 1byte?

Yeah, those are both leftovers from the 16-bit code. I'll fix them up in 
the next version, if the approach looks good..

> 
> Thanks.
> 
--
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/