linux-kernel - RE: Staging: add 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]

Message-ID: <07905E0D268758488D76D7D747F21BB602B1FD86@rdc8.rdc>
Date:	Tue, 23 Jun 2009 10:16:03 +0800
From:	Kevin Huang (黃凱文) <Kevin.Huang@....com.tw>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Cc:	<greg@...ah.com>, <torvalds@...ux-foundation.org>
Subject: RE: Staging: add pata_rdc driver

I just know all pata follow the ATA ATAPI Host Adapters Standard.pdf.
This standard describes all hardware interfaces for pata. (like sata and AHCI standard spec.)

The original draft does not have any Configuration Registers for Host Adapters. Then Intel proposes ATA Controller PCI Configuration Registers for this lack of the original draft, and T13 accept this proposal.

But this spec. releases at 2003. So before its release, all vendor had own Configuration Registers. Our new controller follows this spec. so that OS can provide a standard driver for pata controller.

Our new controller have crypto function and crypto configuration registers.
So it don’t like Intel controller.
Some Intel controller have RAID function, but we have not.

-----Original Message-----
From: Alan Cox [mailto:alan@...rguk.ukuu.org.uk] 
Sent: Monday, June 22, 2009 8:32 PM
To: Linux Kernel Mailing List
Cc: greg@...ah.com; torvalds@...ux-foundation.org; Kevin Huang (黃凱文)
Subject: Re: Staging: add pata_rdc driver

> +static struct pci_bits ATA_Decode_Enable_Bits[] = { // see ATA Host Adapters Standards.
> +    { 0x41U, 1U, 0x80UL, 0x80UL },    /* port (Channel) 0 */
> +    { 0x43U, 1U, 0x80UL, 0x80UL },    /* port (Channel) 1 */
> +};
> +

Decode bits 0x80 in 0x41/0x43 - same as ata_piix

> +    /* no hotplugging support (FIXME) */ // why???

copied from the piix driver

> +        Mask = ATAConfiguration_IDEIOConfiguration_PrimaryDeviceCable80Report;

Cable bits at 0x54: same format as ATA_PIIX

and this continues throughout the driver

So it seems the following occurred

- take ata_piix
- remove all the innards of it
- replace them with identically functional but convoluted vendor code for
the same actual hardware interface
- submit as new driver

Would someone please tell me wtf is going on here and why if the hardware
is so close to ata_piix it doesn't either use the piix driver or if its
very similar just use bits of it as was (as efar, mpiix and oldpiix do) ?

What if anything actually differs between Intel PIIX and the new RDC
controllers ? Why can't we just cp ata_piix.c ata_rdc.c and just remove
all the intel specific casing ?

Alan
---------------------------------------------------------------------------------- 
[E-mail Confidentiality Notice]
The information in this e-mail is confidential and may be legally privileged 
otherwise  protected from disclosure. It is intended solely for the 
addressee.  Access to this e-mail by anyone else is unauthorized .If you
are not the intended recipient, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it, is prohibited and 
maybe unlawful.  Please delete the message and any attachments from 
your computer system; and destroy all hard copies. 

ALL Intellectual Property Rights of RDC Reserved.
----------------------------------------------------------------------------------