That’s a complicated question (and a difficult task, especially since the port is going from a 64-bit architecture to a 32-bit architecture…I wouldn’t recommend it). Back-porting is typically something Santiago does for his Grinch kernels…he’s the expert on this:
In general, there would be an architecture independent directory in the kernel source for that driver (somewhere under “drivers/”). Some Kconfig files would make this available for config setup. One would copy that driver directory branch into the older kernel source, and set up Kconfig.
Firmware would be an additional step for wireless, which has an architecture dependent directory somewhere in the “arch/” subdirectory tree, and would need to be copied into “arm” subdirectory from the “arm64” directory.
There is no telling what would be required to support making the driver compile, as changes from this older kernel to the newer one may make some features used by the driver non-existent when put in the older environment. Basically, the newer infrastructure the module depends upon may require modifying the driver to run on older infrastructure. This could include differences in compilers, and not just code in the driver (especially where arm versus aarch64 is concerned).
The firmware would have to be adjusted for whatever changes are needed in the driver.
To make things more difficult, sometimes there is more than one driver for a device. For example, some wireless devices also have bluetooth…the bluetooth would have its own driver and firmware. If I were you I’d start by learning to back port a simple driver from the same 32-bit ARMv7 driver as close to the near future of the 3.10.40 kernel as possible. Then I would try to just get the driver you are actually working on to compile…but not necessarily be able to load or run. To get further you’d then have to port the firmware. Once the firmware is done, you could work on getting the module to load and then to run.