Hello Michael, Michael Leun <lkml20130...@newton.leun.net> writes:
> I would vote to not accept that driver for mainline as long as this > issues are not fixed. > > The vendor should not be able to claim "hooray, hooray, great device, > we even have an driver in linux main line" when it is actually such an > useless crap. Well, that is fortunately not how these things work. The main goal is getting the devices supported in the kernel. Bugs can be fixed. If a vendor can get any positive gain out of having a driver in mainline, then that is good for everyone, isn't it? Of course, we can all agree that the effect of a *working* driver is more positive than a non-working driver... For now, the main focus should be fixing the issues which has been noted during review. Your testing feedback is of course very useful, but you probably need to back them up with actual code change proposals if they are going to be dealt with at this stage. > Of course I'm offering to help with any information or testing, but > unfortunately I do not have the knowhow to fix anything myself. I believe this is where you are totally wrong. You obviuously have the ability to create a few simple test cases for yourself and see if the driver behaves as you expect. That is very useful. And you have a device. That is also useful. Now, the driver source code is available. And there is another Asix driver in the kernel which already has been cleaned up and can be used as an example. And maybe even partly used for the new devices as well, if the code is duplicated? I have not looked at this in detail, but I suspect that much of the problem with the ax88179_178a driver is that it has completely ignored all the work that has gone into the asix driver after it was mainlined. I find it unlikely that there is no reusable code in the asix_devices.c, asix_common.c and ax88172a.c files. Trying to rewrite ax88179_178a to share as much code as possible seems like the best way to clean it up and fix bugs. You have documents like http://www.kernel.org/doc/Documentation/SubmittingPatches helping a lot with cleanup jobs like this, because it is mostly about just following that recipe. If you do, then the code will be reviewable by the community because the size will be reduced and the style readable. And the driver might even work, as the cleanup will quite possibly reveal a number of bugs... Please consider this option. Reading and fixing up C code is not very difficult. Getting this driver into the kernel in a good shape is mostly just monkey work. But some monkey has to do it :-) Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html