On 13/05/10 09:13, Alan Cox wrote: >>> I don't think ide-platform matters in this case. >> >> You've just supported a patch restoring feature parity between >> pata_platform and ide-platfrom WRT IRQ flags. ;-) > > Because it was trivial to do. > >> Yes, but this needs to be *done* too, preferrably by the author of >> the original patch and simultaneously with it. We can't accept a single >> patch that only touches pata_platform. I'm happy to expand the patch, but why would we implement such a thing in a legacy driver. Odds are that nobody would ever use it. If I had developed my code prior to pata_platform and used the old IDE driver instead I would of patched it then (and it may have been included in pata_platform). If anyone requires this hook from today on, odds on it is for a new system and the old IDE driver will not even be considered for the task. Besides, by only implementing these features in the latest (supported) drivers, it will encourage people to move away from the legacy drivers which is a Good Thing(tm) > > Sure - or support it in both. I've no problem with both supporting that > function, just with legacy code blocking progress. > >> Well, with 8250 we still don't allow for overriding things at the >> board level, via the platform data callbacks. > > Oh yes we do. Platform specific drivers can directly override the access > operators and they do some truely horrible platform specific stuff in the > overridden operators. > > And the great thing - nobody else has to know what the board vendors have > been on.. > Exactly - This is good driver design. Implement the fundamentals for the majority of use-cases and provide overrides to allow individual implementations which can do anything weird and wonderful without polluting the code space of everyone else. Regards, Graeme -- 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
