I could also rip out TX4939 part from the patch and leave Atsushi to deal with the fallout (though I could give him the ripped out part to simply be merged to the driver) if you would queue my patchset ahead of the driver. Though I feel it's too late now for my patchset to get into 2.6.28 the way things have been happening... :-/Also I didn't know anything about your patchset and itsThe patchset consists of a large patch moving read_sff_dma_status() to its porper place, one small preparatory patch, and 2 followup patches, so unfortunately it's dependent on TX4939 in its main patch (worse, the relevant part of this driver has changed after your last merged driver version)...
dependency on TX4939, otherwise I'll be pushing things in
different order or even skip this pull request if neededUnfortunately, that driver has been submitted first back 9/09, long before my patchset was even created, so the dependence was just natural.
(TX493x drivers are new stuff and were still under review,
such things can be also submitted after the merge window
closes so they were given the lowest priority).
Ehm, submitting things _before_ the merge window usually help. ;-)
Anyway, no need to get too frustrated over it. It is normal that