Alan Cox posted an updated LibATA PATA (IDE) status report on the lkml. Improved from a previous status report [story] he noted, "current kernels now support HPA (Host Protected Area) but default to honouring it. Probably a wrong default for PATA but we need to decide the right way to expose it nicely." He went on to note, "no PATA hotplug support yet. Need warmplug helpers for some chipsets (eg some intel ICH) to avoid risk of hangs."

Later in the report he listed around 40 chipsets describing LibATA's PATA support for each, ranging from "rock solid" for ATIIXP and "solid" for AMD, TRIFLEX, MARVELL, MPIIX, OLDPIIX, NETCELL, RZ1000, SERVERWORKS, SIL680, and VIA, to "still experimental" for NS87410 and "no idea" for IT8213. When asked about support for PowerPC drivers, Alan replied, "I'm not aware of anyone having done any PPC ports yet, although a couple of people have asked and said they would look at it. Currently our coverage is incomplete for some embedded and obscure platforms, of which the macintrash is probably the least 'obscure'."

Jeff Garzik noted that the hardware documentation for the Promise SX4 chipset is being opened up and therefor the sata_sx4 driver is a good candidate for improvements, "I would like to take this opportunity to point hackers looking for a project at this hardware. The Promise SX4 is pretty neat, and it needs more attention than I can give, to reach its full potential." He notes that it is an older chipset that's probably not sold anymore, that the ATA programming interface is similar to that in the sata_promise driver, and that it contains a fully programmable on board DIMM and on board RAID5 XOR. Jeff went on to explain:

"A key problem is that, under Linux, sata_sx4 cannot fully exploit the RAID-centric power of this hardware by driving the hardware in 'dumb ATA mode' as it does. A better driver would notice when a RAID1 or RAID5 array contains multiple components attached to the SX4, and send only a single copy of the data to the card (saving PCI bus bandwidth tremendously). Similarly, a better driver would take advantage of the RAID5 XOR offload capabilities, to offload the entire RAID5 read or write transaction to the card.

"All this is difficult within either the MD or DM RAID frameworks, because optimizing each RAID transaction requires intimate knowledge of the hardware. We have the knowledge... but I don't have good ideas -- aside from an SX4-specific RAID 0/1/5/6 driver -- on how to exploit this knowledge."