Hi Wolfgang, Wolfgang Reissnegger wrote: > David H. Lynch Jr. wrote: > >>For me the most significant issue is the bazillion layers of nested >>macro's and includes. > > > I don't see the macros as an issue, just look at the implementation of, > for example, spin_lock_irq() and Xilinx's macros seem like child's play :-) > As for includes, yes, there are a few too many header files. But, as > time progresses and the need arises they can be merged into fewer files.
It seems the kernel.org decision has been made re: the style issue. None of the *_i.[ch], *_g.[ch] + adapter.c drivers will make it to mainline. I understand why Xilinx did it this way, but to be honest never agreed with it myself either. Style issues aside, three levels of function calls in an interrupt handler might be portable, but it still isn't a good thing! The effort to refactor these drivers is not huge, but it is an effort. If Xilinx is committed to good quality Linux support for their silicon, it will require tangible investment in the form of labour or resources. I know you understand this, but Xilinx as an company still needs a good hard shove in this direction. Alternatively, drivers will trickle into kernel.org as the community gets around to it, witness the uartlite and system ace drivers. Same old story, if you want it "some day", then it will be free, if you want it now, you've got to pay! Cheers, John _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded