Hello. Bartlomiej Zolnierkiewicz wrote:
* Split off hpt{374,371,366}_init() helper from init_setup_hpt{374,371,366}().
* Merge init_setup_{374,372n,371,372a,302,366}() into hpt366_init_one().
While at it:
* Use "HPT36x" name for HPT366/HPT368 chipsets.
* Add .chip_name to struct hpt_info and use it to set set d->name.
* Convert .max_ultra in struct hpt_info to .udma_mask and use it to set d->udma_mask.
* Fix hpt302 to use HPT302_ALLOW_ATA133_6 define.
I haven't found that change...
After wearing better goggles, I had found it. ;-)
static struct hpt_info hpt302 __devinitdata = { + .chip_name = "HPT302", .chip_type = HPT302, - .max_ultra = HPT372_ALLOW_ATA133_6 ? 6 : 5, + .udma_mask = HPT302_ALLOW_ATA133_6 ? ATA_UDMA6 : ATA_UDMA5, .dpll_clk = 66, .settings = hpt37x_settings };
* Use the second hpt366_chipsets[] entry for HPT37x chipsets using HPT36x PCI device ID and fix .enablebits/.host_flags for HPT36x hpt366_chipsets[] entry.
Well, if you're ruining my nearly perfect desigh...
I was just adjusting hpt366 for ->init_setup removal, the other changes
Well, the code was looked good enough w/it although it wasn't really a method being called only by in the module_init() time...
happened by the way... 8)
I wanted to both use the newly introduced init. time 'udma_mask' field, and needed this later -- but somehow disliked repeating the masks, so kept the max UDMA mode in the 'struct hpt_info'...
* Bump driver version.
... it's worth to label it 1.20. :-)
updated
+ d = hpt366_chipsets[idx]; + + d.name = /info->chip_name; + d.udma_mask = info->udma_mask; + + pci_set_drvdata(dev, info); + + if (info == &hpt36x || info == &hpt374) + dev2 = pci_get_slot(dev->bus, dev->devfn + 1); + + if (dev2) { + int ret; + + pci_set_drvdata(dev2, info); + + if (info == &hpt374) + hpt374_init(dev, dev2); + else { + if (hpt36x_init(dev, dev2)) + d.host_flags |= IDE_HFLAG_BOOTABLE; + } + + ret = ide_setup_pci_devices(dev, dev2, &d); + if (ret < 0) + pci_dev_put(dev2); + return ret; + } - return d.init_setup(dev, &d); + return ide_setup_pci_device(dev, &d); }
NAK the patch because it's breaking the HPT374 code. Those chips are *signle* function, and sit in perfect copule (and why I alsway mistype in this word :o) on 2 DEVSELs behind i960.
Sigh... I've just mixed it all up with PDC202xx chips, after looking at their init_setup() code -- I'm making a Promise not to do it anymore. :-)
Please explain - there shouldn't be any behavior change for HPT374 caused by this patch.
Could it be that HPT374 code was already buggy
Hehe, we *know* that it's buggy, what we do not know is where and why. ;-)
Bart
MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html