Alan,
So look for yourself, this is extracted straight out if the patch
submitted to LKML. It is very clear, without the NDA Documentation and no
hardware to perform a clean-room new driver. Without the is information,
one could not write a driver for the hardware.
Now to quote Vojtech,
"After getting a couple reports that the Artop driver doesn't work, I
decided to take a look at it ... well and I decided that this is
impossible to debug, so I rewrote it from scratch instead. I have no
documentation nor the actual hardware, so it may be wrong somewhere,
but I think definitely less wrong than the original one."
*****************
ChangeSet@1.657, 2002-05-24 15:34:29+02:00, vojtech@twilight.ucw.cz
This is a new driver for the Artop (Acard) controllers. It's completely
untested, as I have never seen the hardware. However, I suspect it is
much less broken than the previous one ...
<comment>
For starters he has no hardware and no documents, and he has read my
copyrighted source code, thus there is no way for him to have a clean room
model.
</comment>
+/*
+ *
+ * $Id: aec62xx.c,v 1.0 2002/05/24 14:37:19 vojtech Exp $
*
- * Version 0.11 March 27, 2002
+ * Copyright (c) 2002 Vojtech Pavlik
*
- * Copyright (C) 1999-2000 Andre Hedrick (andre@linux-ide.org)
+ * Based on the work of:
+ * Andre Hedrick
+ */
<comment>
All that has to be done is return proper CopyRight clauses.
</comment>
+static unsigned char aec_cyc2udma[17] = { 0, 0, 7, 6, 5, 4, 4, 3, 3, 2, 2, 2,
2, 1, 1, 1, 1 };
-
-struct chipset_bus_clock_list_entry aec62xx_base [] = {
-#ifdef CONFIG_BLK_DEV_IDEDMA
- { XFER_UDMA_6, 0x41, 0x06, 0x31, 0x07 },
- { XFER_UDMA_5, 0x41, 0x05, 0x31, 0x06 },
- { XFER_UDMA_4, 0x41, 0x04, 0x31, 0x05 },
- { XFER_UDMA_3, 0x41, 0x03, 0x31, 0x04 },
- { XFER_UDMA_2, 0x41, 0x02, 0x31, 0x03 },
- { XFER_UDMA_1, 0x41, 0x01, 0x31, 0x02 },
- { XFER_UDMA_0, 0x41, 0x01, 0x31, 0x01 },
-
- { XFER_MW_DMA_2, 0x41, 0x00, 0x31, 0x00 },
- { XFER_MW_DMA_1, 0x42, 0x00, 0x31, 0x00 },
- { XFER_MW_DMA_0, 0x7a, 0x00, 0x0a, 0x00 },
-#endif /* CONFIG_BLK_DEV_IDEDMA */
- { XFER_PIO_4, 0x41, 0x00, 0x31, 0x00 },
- { XFER_PIO_3, 0x43, 0x00, 0x33, 0x00 },
- { XFER_PIO_2, 0x78, 0x00, 0x08, 0x00 },
- { XFER_PIO_1, 0x7a, 0x00, 0x0a, 0x00 },
- { XFER_PIO_0, 0x70, 0x00, 0x00, 0x00 },
- { 0, 0x00, 0x00, 0x00, 0x00 }
-};
<comment>
New table is purely derived from the previous table.
It is clever to hide the push/pull in the index based on the card.
This will generate the associated pairs identically from the static table.
</comment>
+#define AEC_MISC 0x49
static unsigned int __init aec62xx_ata66_check(struct ata_channel *ch)
{
- u8 mask = ch->unit ? 0x02 : 0x01;
- u8 ata66 = 0;
+ unsigned char t;
- pci_read_config_byte(ch->pci_dev, 0x49, &ata66);
-
- return ((ata66 & mask) ? 0 : 1);
+ pci_read_config_byte(ch->pci_dev, AEC_MISC, &t);
+ return ((t & (1 << ch->unit)) ? 0 : 1);
}
<comment>
Here he moves a specified pci-config space register to a define.
Next he trades the mask for a bit shift.
Next he renames the test variable.
</comment>
- pci_read_config_word(dev, 0x40|(2*drive->dn), &d_conf);
- tmp0 = pci_bus_clock_list(speed, aec62xx_base);
- SPLIT_BYTE(tmp0,tmp1,tmp2);
- MAKE_WORD(d_conf,tmp1,tmp2);
- pci_write_config_word(dev, 0x40|(2*drive->dn), d_conf);
-static int aec6260_tune_chipset(struct ata_device *drive, byte speed)
-{
- struct pci_dev *dev = drive->channel->pci_dev;
- byte unit = (drive->select.b.unit & 0x01);
- u8 ultra_pci = drive->channel->unit ? 0x45 : 0x44;
- byte drive_conf = 0x00;
-static int aec6210_tune_chipset(struct ata_device *drive, byte speed)
-{
- pci_read_config_byte(dev, 0x54, &ultra);
- tmp1 = ((0x00 << (2*drive->dn)) | (ultra & ~(3 << (2*drive->dn))));
- ultra_conf = pci_bus_clock_list_ultra(speed, aec62xx_base);
- tmp2 = ((ultra_conf << (2*drive->dn)) | (tmp1 & ~(3 << (2*drive->dn))));
- pci_write_config_byte(dev, 0x54, tmp2);
+#define AEC_DRIVE_TIMING 0x40
+#define AEC_UDMA_NEW 0x44
+#define AEC_UDMA_OLD 0x54
+ pci_write_config_byte(dev, AEC_DRIVE_TIMING + dn,
+ (FIT(timing->active, 0, 15) << 4) | FIT(timing->recover, 0, 15));
+
+ pci_read_config_byte(dev, AEC_UDMA_NEW + (dn >> 1), &t);
+ t &= ~(0xf << ((dn & 1) << 2));
+ if (timing->udma)
+ t |= aec_cyc2udma[FIT(timing->udma, 2, 16)] << ((dn & 1) << 2);
+ pci_write_config_byte(dev, AEC_UDMA_NEW + (dn >> 1), t);
<comment>
These are a little more difficult to see
Here he adds a skip masking order to merge timings into one call.
</comment>
*****************
Regards,
Andre Hedrick
LAD Storage Consulting Group
AEC6280R: IDE controller on PCI bus 02 dev 20
AEC6280R: chipset revision 2
AEC6280R: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xa008-0xa00f, BIOS settings: hdg:pio, hdh:pio
AEC6880R: IDE controller on PCI bus 02 dev 28
AEC6880R: chipset revision 2
AEC6880R: not 100% native mode: will probe irqs later
ide4: BM-DMA at 0xb400-0xb407, BIOS settings: hdi:pio, hdj:pio
ide5: BM-DMA at 0xb408-0xb40f, BIOS settings: hdk:pio, hdl:pio
Controller: 0
Chipset: AEC865
--------------- Primary Channel ---------------- Secondary Channel -------------
enabled enabled
--------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------
DMA enabled: yes no yes no
DMA Mode: UDMA(5) PIO(?) UDMA(5) PIO(?)
Controller: 1
Chipset: AEC865
--------------- Primary Channel ---------------- Secondary Channel -------------
enabled enabled
--------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------
DMA enabled: yes no yes no
DMA Mode: UDMA(6) PIO(?) UDMA(6) PIO(?)
Nor could one know the detection difference between the two chipset with
the same device id and revision.
02:04.0 SCSI storage controller: Artop Electronic Corp: Unknown device 0009 (rev 02)
02:05.0 SCSI storage controller: Artop Electronic Corp: Unknown device 0009 (rev 02)
On 27 May 2002, Alan Cox wrote:
> On Mon, 2002-05-27 at 00:08, Andre Hedrick wrote:
> > All of the original code described how to make the hardware operate. If
> > your code makes the hardware operate, then it uses material copyrighted
> > and owned by me.
>
> Really. You think if I read a GPL'd example of a piece of code I can't
> write a non GPL'd one. Companies use two sets of people to ensure that
> there are no questions (one set write the spec, the other to write from
> that spec in a different building).
>
> > I suggest you think real hard and long about your decisions to go about
> > calling derived works from stolen/deleted Copyrights.
>
> Rude yes, but derived work.. open question. I guess Eben can give you a
> reasonably sane opinion if its so important.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri May 31 2002 - 22:00:19 EST