Closed jasmas closed 8 years ago
Hope you don't mind me saying this, but your question is not very precise. It is possible to backport the driver (quote: "this")? Yes, the driver and the stack are free software after all. Am I going to do this? No, I'm busy with more interesting things :(
I think your safest bet, actually, is to try the driver backport thing: https://backports.wiki.kernel.org/index.php/Main_Page http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backports/ It used to be very cool and polished but the development seemed to have slowed down a little. I had a look at the page and they seem to have a 4.2 release up there. I think it would be better to get 4.3 (I fixed a DMA bug in 4.3) but perhaps 4.2 will work for you just fine. If it doesn't backporting my changes from 4.3 shouldn't be a big deal. There weren't very many changes to the driver: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?qt=grep&q=mt7601u
Happy hacking!
You set me off on the right track. It was trivial to pull the backport source and cherry pick your patches. Now I'm just having some sort of logistical challenge. I'm getting the backport driver to build against my test machine with a newer kernel, but not the target kernel, version 3.10 on arm.. It just skips over the mt7601u driver for some reason when compiling without any error messages or anything. It builds all the other drivers, but there is something about my target kernel and that specific driver causing it to not configure it correctly. I'm wondering if it has to do with features of the driver not backported
I'm thinking it may have to do with something that needs to be built modular in my target kernel? Realize this isn't your issue, man, but I appreciate your help from before and any other advice you can give me.
I got it figured out, my friend. Original kernel was compiled without crypto libraries that were needed. Thanks again.
Is it possible to backport this to 3.10?