How to deblob a kernel patch

Sometimes, there are drivers aren't available from official Linux kernels such as specific drivers and device trees for ARM architecture adapted for certain SoCs, however a lot of them contains nonfree drivers or blobs, then is needed deblob them to protect your freedom.

What is a blob?

A Blob is a piece of object code distributed without source, usually firmware to run some device. That firmware is distributed only in object code form, under a nonfree license.

What is deblobbing?

Deblobbing is the way to remove blobs from the source or patches.

deblob-check

deblob-check is a script written by Alexandre Oliva. It is the easiest way to looking for blobs to remove them from kernel sources and kernel patches.

How to use deblob-check to deblob kernel patches?

The command to begin deblob a patch is check the sequences that match the blob detector test with -B, eg:

./deblob-check  -B name.patch

Common results could be such as:

err = request_firmware_direct(&ditem->fw, item->overlay_name, dev);

and

#define WL18XX_CONF_FILE_NAME "ti-connectivity/wl18xx-conf.bin"

In this case, you should check if those references were deblobbed in deblob-x.y of the kernel version that you are using. You can get it at the Linux-libre scripts page (eg. 4.9-gnu).

If those references aren't available in Linux-libre source yet, then you should check if those references aren't false positives. If the first reference (eg. request_firmware_direct) is requesting a blob, then you should rename request_firmware_direct to reject_firmware_direct and if the second one (wl18xx-conf.bin) is a blob, you must replace it with /*(DEBLOBBED)*/ , eg:

err = reject_firmware_direct(&ditem->fw, item->overlay_name, dev);

and

#define WL18XX_CONF_FILE_NAME "ti-connectivity/wl18xx-conf/*(DEBLOBBED)*/
If you found blobs included inside the patch, you must remove it manually with your favourite editor (eg. vim)
Not all “.bin” files aren't blobs, you should check if they contains source code under a free license. Otherwise, some of them could be a short sequence of register accesses that aren't copyrightable, so the license is irrevelant and are consider false positives.
deblob-check could match things such as dtc-lexer.lex.c_shipped as blobs, however they are false positives since are regular expression processing tables.