> I would vote to not accept that driver for mainline as long as this > issues are not fixed.
Michael, could you give me more information about how do you test this driver? I have tried to reproduce the issue by using "ifconfig ethX mtu 1500", but I didn't confront the same issue. Thank you in advance for your help. > 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. Bjørn, I am trying to reproduce the issue mentioned by Michael and I have a question about submitting this driver. Should I merge this driver into asix_devices.c and asix_common.c even through the usb command, tx_fixup, and rx_fixup functions are totally different? Thank you in advance for your reply. Freddy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
