Hello.
Alan Cox wrote:
- the driver doesn't serialize access to the channels depending on the current
clock mode like the vendor drivers, so the clock turnaround is only executed
"optionally", not always as it should be;
The vendor driver I have uses that algorithm. I think I prefer your
approach however !
Does it have the *ClockCapable() things? These functions seem to
implement command deferring much like hpt3x2n_qc_defer() does now.
- the wrong ports are written to when hpt3x2n_set_clock() is called for the
secondary channel;
Ouch.
Same as in the IDE driver... I really should have taken a closer look
at the libata driver earlier.
- hpt3x2n_set_clock() can inadvertently enable the disabled channels when
resetting the channel state machines.
Yep.
Same as in IDE driver too. I guess you've copied this from the vendor
driver that also does this.
Could you give this a bit of testing? I don't have HPT371N at hand, and it's
seated in the board with 66 MHz PCI anyway...
I'm not likely to have a chance to do so until next year.
That's a pity... well, then we probably have to commit it untested. :-)
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
