OpenWrt Forum Archive

Topic: Kernel patch is not included in compilation

The content of this topic has been archived on 5 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hello

I'm trying to apply a kernel patch regarding the ath9k module and followed the wiki article for that.(Working with patches)

The problem I'm experiencing is the following, the changes don't seem to be included in the compilation, although the files in the build directory have the patched content. I am assuming that somehow those files are not used, as of right now, I added some gibberish that should produce an error during compilation, all in a patch. I can see the changes, but the compilation goes through without an error, which should not be the case. The file I added the gibberish to is the debug.c for ath9k.

Can someone help me with this or can see a mistake I am making? I am really confused right now.

Kind regards
Kacha

Kacha wrote:

The problem I'm experiencing is the following, the changes don't seem to be included in the compilation, although the files in the build directory have the patched content. I am assuming that somehow those files are not used

After changing kernel patches, you need to "make clean" before the next compilation.

Where are you placing the patches?
And exactly which "build directory" we are now talking about?

"make target/linux/clean" should clean the kernel build.
"make target/linux/prepare" should unpack the sources again and apply the patches
"make target/linux/compile" should then compile the kernel.

But when talking about ath9k changes, I think that you might actually be talking about the mac80211 kernel package. Thus:
make package/mac80211/{clean,prepare}
make package/mac80211/compile

For mac80211 patches, the place for patches should be <build_root>/package/kernel/mac80211/patches/

(Last edited by hnyman on 16 Feb 2016, 15:20)

Kacha wrote:

I'm trying to apply a kernel patch regarding the ath9k module and followed the wiki article for that.(Working with patches)

If you followed the wiki, then make sure your patched file gets applied with quilt push. Once you have done that, you can use any text editor to edit the file patched by quilt to see if the quilt push has made the changes to the file. If not, then there is something wrong with your patched file. Otherwise, proceed as explain above by hnyman.

hnyman wrote:

After changing kernel patches, you need to "make clean" before the next compilation.

Where are you placing the patches?
And exactly which "build directory" we are now talking about?

The files I am changing are in ./build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_generic/linux-3.18.23/drivers/net/wireless/ath/ath9k/. The quilt stuff was done in ./build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_generic/linux-3.18.23/. In that directory I can also see my patch files in ./patches/platform

hnyman wrote:

"make target/linux/clean" should clean the kernel build.
"make target/linux/prepare" should unpack the sources again and apply the patches
"make target/linux/compile" should then compile the kernel.

I did that as the wiki suggested, there they have it in one command "make target/linux/{clean,prepare} V=s QUILT=1", I also compiled it again.

hnyman wrote:

But when talking about ath9k changes, I think that you might actually be talking about the mac80211 kernel package. Thus:
make package/mac80211/{clean,prepare}
make package/mac80211/compile

For mac80211 patches, the place for patches should be <build_root>/package/kernel/mac80211/patches/

I just looked at that package, it seems to change the same files as the the patches in the directory I mentioned above. What is the difference here?

mazilo wrote:

If you followed the wiki, then make sure your patched file gets applied with quilt push. Once you have done that, you can use any text editor to edit the file patched by quilt to see if the quilt push has made the changes to the file. If not, then there is something wrong with your patched file. Otherwise, proceed as explain above by hnyman.

I did apply the patch with quilt push, also "make target/linux/{clean,prepare} V=s QUILT=1" shows that the patch is applied. The patch file itself was created through quilt, so I don't think there is something wrong with the patch file.

(Last edited by Kacha on 16 Feb 2016, 16:11)

Kacha wrote:
hnyman wrote:

For mac80211 patches, the place for patches should be <build_root>/package/kernel/mac80211/patches/

I just looked at that package, it seems to change the same files as the the patches in the directory I mentioned above. What is the difference here?

<build_root>/package/kernel/mac80211/patches/ is the original/correct location for patches for that package, and the patches from there are applied to the kernel during the build. To my knowledge, ath9k wireless pacthes should be there.

I guess that what may be happening, is that you are patching the files directly in the kernel directory, but as those files are managed by the mac80211 package, those files will get overwritten during the build with the actual package-specific patches from <build_root>/package/kernel/mac80211/patches/ . Or something similar.

Ps.
I have never bothered to use QUILT=1. I have simply "prepared" or "compiled" the sources, and then have edited the file manually. Then a diff against the original (which I copied before editing it) and we have a patch that can be safely placed as the last in the queue of the package's patch directory.

hnyman wrote:

<build_root>/package/kernel/mac80211/patches/ is the original/correct location for patches for that package, and the patches from there are applied to the kernel during the build. To my knowledge, ath9k wireless pacthes should be there.

I guess that what may be happening, is that you are patching the files directly in the kernel directory, but as those files are managed by the mac80211 package, those files will get overwritten during the build with the actual package-specific patches from <build_root>/package/kernel/mac80211/patches/ . Or something similar.

That may very well be the case. I will try that out. Thanks for the tip!

The discussion might have continued from here.