Re: [PATCH] Submitting PROMISE IDE Controllers Driver Patch

["Hank Yang" <hanky@promise.com.tw>]

We do hope the linux kernel add some code on ide-pci.c like following.

void __init ide_scan_pcidev (struct pci_dev *dev)
{
 ide_pci_devid_t  devid;
 ide_pci_device_t *d;

 devid.vid = dev->vendor;
 devid.did = dev->device;
 for (d = ide_pci_chipsets; d->devid.vid && !IDE_PCI_DEVID_EQ(d->devid,
devid); ++d);
 //Ignored by Promise
 if ((dev->vendor==PCI_VENDOR_ID_PROMISE) && ((dev->class
>>8)==PCI_CLASS_STORAGE_RAID))
 {
  printk("%s: ignored FastTrak series by PROMISE.\n", d->name);
  return;
 }

Then, we won't affect other IDE controller or ATA-RAID controllers.
We can provide our ATA-RAID controller's driver by our own.

Hank

> > > The ataraid driver in the standard kernel requires the IDE drive is
seen
> > > by the ide layer otherwise ataraid cannot bind it into a raid module
> >
> > First, the IDE driver doesn't check the controller's class code is raid
> > controller (0x0104) or other controller(0x0180). So If our raid
controller
> > (FastTrak series) be seen by IDE driver. It will snatch the same IRQ.
> > It will cause our trouble.
>
> It wants to. What happens is this
>
> - The IDE layer detects the raid chip
> - We check it isnt a supertrak hardware raid
> - If it isnt we add the chips as basic ide devices
> - The ataraid module loaded on top of those opens the ide disks and
> hunts for promise and hpt raid descriptors
> - When it finds the raid descriptor it creates an additional
> /dev/ataraid/.... device
>
> Because our ataraid driver actually sits on top of the existing IDE
drivers it
> requires they grab the devices. This also allows end users to issue
commands
> directly to the drives (for example for SMART)
>
> Alan