Closed alifilhan0 closed 1 year ago
Hi, I don't know if you can use mainline btif driver.
My repo is based on mainline,so you can easily use the patches to include the wifi driver, but i guess you want to avoid this buggy wmt driver.
If i would know a way to get mt6625 working without this driver i would not use this driver.
Actually I have a device with MT6735 and MT6625L IC, want to run a totally mainline linux kernel on it. I think the kernel will have support for almost everything except the Camera ISP, WiFi, BT, GPS and the Baseband Cellular 2/3/4G modem(since older MTK SoC basically share almost same IP blocks among them). So as you say there's no way to get MT6625 in mainline, I am thinking of using the vendor driver codes+firmware I have from BSP for these missing parts. I just want to know then how the Android driver for MT6625 was ported to linux. Any hints? Also, I know a chinese site where we can get the datasheet for this chip if is needed. Will it be worth by looking into those datasheets and find out the similarities between MT76 and this MT6625, then use the mainlined bits from the linux kernel?
At least this driver i have cannot be upstreamed to mainline as it is huge and dirty.
Some user on bpi-forum told me he asked felix from openwrt (main contributor of mt76 driver) and got response that mt6625 cannot be integrated in mt76,basicly it needs complete rewrite outside of mt76.
As i have not seen register writes in driver yet...only wmt commands translated to mac80211 and cause of much files i still don't know how driver really works...i only try to get it running on newer linux versions by fixing compile errors :)
But if you are experienced with wifi-drivers you're welcome to help. Note that my version of this driver contains only the wifi/bt part.no lte, fm,gps,..some parts i have removed to make it a bit more clear
Driver von bpi/internet is mostly kernel 3.8/4.4,imho i'm the only one who have upported the driver
Unfortunately I have 0 experience in wifi drivers. Currently I was working on a PMIC of mediatek mt6328 to get it running with linux kernel. And as there is no work going about these MT66xx chips in the mediatek upstream group, I don't think we will ever see a mainline driver for this chip. Again the consys driver is also nonexistent, I don't also think there will be a mainline version of this either. We are maybe stuck with the complete mess of vendor code provided as sources. Do you have any idea about any of these chips being worked on in the linux kernel? Because these chips are out there in the market in huge quantities, I have a mediatek phone with MT6627 wireless ic, and again, this is also not supported. The only info I could get from the driver is that it basically selects the channel and loads the firmware of the MT6625 from filesystem. Then the rest work is done by enabling the device and then the firmware. This is all I know
I only know code for 3.18,4.4 and 4.9 (lede from bpi where my code based of).afair 662x and 663x are compatible
Maybe if you have newer kernelversion on your phone you could ask your phone vendor for source.maybe code is in better shape then the driver i used from 4.4/4.9 but i guess it will depend on android framework so you need changes to make it working with linux kernel
My kernel version is 4.4, as for 90% mediatek phones on the market. The board with MT6735 has kernel source 3.18. It is a big miracle that I got kernel sources for both of these mediatek devices. But again, there is no other way I guess for these MT6625L chips to work in mainline without using those messy drivers. Have you tried building with GPS and Bluetooth for this kernel, regardless the version and did it work? What are the basic changes required to get this messy driver to build with the linux kernel, along with the Bluetooth at least?
Gps is not included in my version. Bluetooth worked in latest test but not btle
Wifi-client was also not working....only ap-mode
I should look out for this, after the wifi-cient mode is fixed, it will at least be usable with mainline kernel for me. But is there any fix for this problem at this moment?
I don't know how to fix the client-mode as is was not working in my 4.9 source too,afair 4.4 was working but i have not found out whats the problem
Vendor posted a 4.14 repo long time after my porting. And mentions wifi client is working
http://forum.banana-pi.org/t/topic/5548
Maybe you can try wifi client from this base and then we can compare differences
Okay, I will try to port in in this week and let you know. Thanks for this
But again, here BT/BLE doesn't work. So something is broken here but working in 4.4. It would take a lot of time I guess. How stable is your 5.4 branch? It does state that BT and WiFi works on the table in README.md doesn't it?
It works in 4.4? Which codebase? Imho bt needs to be compiled as module and loaded after wmt-loader and stp_uart_launcher called
Btle issue was reported here (without solution): http://forum.banana-pi.org/t/bpi-r2-kernel-bluetooth-module/4592/64
I think I remember a message in he Bpi forums a few days ago mentioning Bluetooth and WiFi working a bit unstably in kernel 4.4. Maybe that person was talking about the vendor kernel. But by the way, does client mode work in 5.4 main? And maybe there's no hope for this situation to get better, given how bad MediaTek is towards open source. No effort for MT66xx chips, or is there? In the kernel 4.14, BT/BLE doesn't work and is stated there in the description also.
I do not remember any posting with kernel 4.4 or wifi in last days.client-mode does not work in all my versions including 4.9 (patches from lede and base for 4.14 and further up porting). Bt should work in lts kernels from 4.14,but require load bt chrdev module loaded after wmt commands
Mainline does not support mt6625 at all...only with additional driver in drivers/misc/mediatek like in my repo od bpi repos
maybe Problems with btle are caused by using mainline btif instead of drivers version
Driver has its own btif driver,but i guess mainline btif is compiled in too
Driver adds MTK_BTIF,but defconfig uses mainline btif
That means we cannot use the mainline BTIF driver from linux kernel. We must completely avoid using wireless features from the mainline kernel for this I think, since it doesn't support the connectivity drivers.
Wifi ap and basic bluetooth was working in my repo (using mainline btif and connectivity driver added by me). I need to look if i used btif from drivers/misc before.
4.14+ uses only mainline CONFIG_SERIAL_8250_BTIF 4.9 (lede patches) use CONFIG_MTK_BTIF from drivers misc only
Lede patch from bpi (i added to 4.9-main) is basicly this
I hope i did not anything wrong due to possible conflicts
If changing to mtk-btif i guess we need to change dts to at least match compatible
btif: btif@1100c000 {
compatible = "mediatek,btif";
reg = <0 0x1100c000 0 0x1000>;
interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_LOW>;
clocks = <&pericfg CLK_PERI_BTIF>, <&pericfg CLK_PERI_AP_DMA>;
clock-names = "btifc", "apdmac";
status = "okay";
};
For now, my curiosity is, will the mainline btif driver actually work? How good is that driver or is it not working at all? As there is no support for MT6625 which contains the RF frontend block, I think the mainline btif driver is also useless here, am I right? So for my purposes, I must start with the misc/mediatek/connectivity /btif /eccci /dual_ccci /ccci_util /conn_md /ccmni directories, and of course, the include/mt-plat directory. By the way, there is also a btcvsd driver, do you know what is that for? Is it for wireless audio like wireless speaker-like functions? Here ccci is the modem purpose, you know that. and ccci_util loads the modem driver.
As i've wrote above 4.14+ of my repo uses mainline btif driver (not drivers/mics/mediatek/btif) and wifi ap and bluetooth (without btle) was working in my quick tests
But can you please explain what are the btif_tx and btif_rx nodes on the device tree? All of the kernels even the 5.13 has it. Actually I am very new to mediatek stuff and didn't understand those two nodes. Their compatible nodes seem to be present in the misc/mediatek/btif/commom directory. What does these two nodes do actually?
I guess currently they do nothing in mainline btif driver.i added them because they are added by mt6625 code.
i grep'd my 5.13-rc source for btif-compatibles
./drivers/misc/mediatek/btif/common/btif_plat.c:208: node = of_find_compatible_node(NULL, NULL, "mediatek,mtk-btif");
./drivers/misc/mediatek/btif/common/btif_dma_plat.c:163: node = of_find_compatible_node(NULL, NULL, "mediatek,btif_rx");
./drivers/misc/mediatek/btif/common/btif_dma_plat.c:189: node = of_find_compatible_node(NULL, NULL, "mediatek,btif_tx");
./drivers/misc/mediatek/btif/common/mtk_btif.c:203: { .compatible = "mediatek,mtk-btif", },
and finally the mainline-driver: ./drivers/tty/serial/8250/8250_of.c:316: { .compatible = "mediatek,mtk-btif",
so at least both drivers use the "mediatek,mtk-btif" compatible, but "mediatek,btif_rx" and "mediatek,btif_tx" is only used by non-mainline-driver (drivers/misc/mediatek)
i also took a look in my config (not only defconfig)...and it looks like MTK_BTIF is set by other options
│ Symbol: MTK_BTIF [=y] │
│ Type : tristate │
│ Defined at drivers/misc/mediatek/btif/Kconfig:1 │
│ Prompt: MediaTek BTIF Driver │
│ Depends on: ARM [=y] │
│ Location: │
│ -> Device Drivers │
│ -> Misc devices │
│ (1) -> Mediatek Peripherals │
│ Selected by [y]: │
│ - MTK_COMBO [=y] && ARM [=y] │
│ - MTK_COMBO_BT_HCI [=y] && ARM [=y] && BT [=y] && MTK_COMBO [=y] │
│ Selected by [m]: │
│ - MTK_COMBO_BT [=m] && ARM [=y] && BT [=y] && MTK_COMBO [=y] │
│ - MTK_COMBO_WIFI [=m] && ARM [=y] && MTK_COMBO [=y] && CFG80211 [=m] │
so the btif-driver from drivers/misc is used...and it looks like mainline btif was dropped/renamed...do not find SERIAL_8250_BTIF...based on compatible above it seems to be merged into default serial driver (i guess handled in 8250_mtk.c which is built if CONFIG_SERIAL_8250_MT6577 is enabled)...
as compatible of btif-node is same and both drivers are builtin, i need to look which driver binds to the node and is active...
at least on my main-router i see messages from from non-mainline-driver (but this looks like error)...do not see address from btif-node in dmesg
$ dmesg | grep -i btif [ 5.514639] MTK-BTIF[E]hal_btif_clk_get_and_prepare(284):[CCF]clk_btif=5cd92d92 [ 5.521974] MTK-BTIF[E]hal_btif_clk_get_and_prepare(290):[CCF]clk_btif_apdma=ba4be72f $ dmesg | grep 1100c000
edit: it is no error, only the error-function is used for printing...but without condition
drivers/misc/mediatek/btif/common/btif_plat.c:
274 #if !defined(CONFIG_MTK_CLKMGR)
275 int hal_btif_clk_get_and_prepare(struct platform_device *pdev)
276 {
277 int i_ret = -1;
278
279 clk_btif = devm_clk_get(&pdev->dev, "main");
280 if (IS_ERR(clk_btif)) {
281 BTIF_ERR_FUNC("[CCF]cannot get clk_btif clock.\n");
282 return PTR_ERR(clk_btif);
283 }
284 BTIF_ERR_FUNC("[CCF]clk_btif=%p\n", clk_btif);
285 clk_btif_apdma = devm_clk_get(&pdev->dev, "apdmac");
286 if (IS_ERR(clk_btif_apdma)) {
287 BTIF_ERR_FUNC("[CCF]cannot get clk_btif_apdma clock.\n");
288 return PTR_ERR(clk_btif_apdma);
289 }
290 BTIF_ERR_FUNC("[CCF]clk_btif_apdma=%p\n", clk_btif_apdma);
291
This is exactly my point. Now, since these drivers are way back from kernel 4.4, I need some fixes with these codes which I an struggling with. Huge amounts of compiler errors. Is there a way to compile ONLY this driver and not the whole kernel again and again so that it is easier to understand the gcc error messages? Note, 1. I am using my vendor code, not this patch tree because I want to try and see if there is a fix around the wifi client mode. 2. make m=
i had many problems getting the driver ported to 4.14 and compilable with recent gcc, i suggest using my codebase as there are many fixes in
Do you have any plans for further at least GPS support in this board? The MT7623 and the MT6625L has GPS IP blocks
no, i have much work in porting the wifi/bt-driver and fixing bugs. as this is mostly a one-man-show all work needs to be done by me. if you can help here, i can merge your work (fixing btle, adding gps or other) i can do ;)
I would be more than glad to help, but the thing is I am not skilled, and it was already hard to patch the old drivers to the new kernel, sometimes I can't find what was changed to what. By the way, a little more off-topic reference, do you think chromium kernel sources might have good info? I actually found standard-style MTK CamISP drivers which can be found nowhere. To make it work with the mainline kernel, I only need to patch it to v4l2_async_notifier_parse_endpoints_by_port to v4l2_fwnode_endpoints_parse And it fulfils my camera driver demand for my project. And it also has a reference to WiFi in the device tree but I don't know about it much. Here's the ISP driver link and I will look if there's a consys module driver too, since it is a Mediatek MT8183, and it shares a lot of IP blocks with MT65xx and other SoCs. Hope it gives us some more info....
Here's the actual kernel https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-4.19/
this is no more i do...i don't know the hardware / driver...just compile and fix issues, then test. I have no documentation and the driver itself is very huge. so i step through the code if something is not working.
Without hardware info, the work done in this repo is already a very big achievement. Hats off...... and I should look more into this issue. I think we can improve more. i will inform you if the GPS is in good condition
getting btle working will be more valuable, isn't it?
First of all, I know very little about BLE, then even by miracle I get it to work, I have no BLE based devices to test. This is mostly an IoT based feature I think though. So what do you think now?
maybe wifi client-mode?
Yeah, this will do. One of my main targets was this one. Can you point me where to start from? Any of your branches working with client mode in the past? Or from scratch vendor codes?
imho vendors 4.4 (maybe 4.14 from vendor) had working client-mode. afair 4.9 (and following) was broken.
4.4 from vendor was not compilable by recent gcc...but you can get gcc-patches from my repo (maybe from x.xx-wifi branch, afair 4.16 was last with gcc patches separately)
start may be the switch-statement for the char passed to wmtWifi
drivers/misc/mediatek/connectivity/common/conn_soc/linux/pub/wmt_chrdev_wifi.c
afair this position:
394 } else if (local[0] == '1') {
395 if (powered == 1) {
396 WIFI_INFO_FUNC("WIFI is already power on!\n");
397 retval = count;
398 goto done;
399 }
....
i see there is only a poweron...maybe this is the problem ;)
in ap-mode there is a device created (control-device, default wlan%s, in my code mt6625l*)
So for the first step, I will build GCC 11.0 with Binutils 2.36 and Glibc 2.33 from sources and try this. Will this be fine? I think the more later compilers the better and Linaro as you showed in your messages had problems with their GCC 5 and GCC 7 right?
currently it is compilable till gcc9 (ubuntu 20.4) in my repo (4.14+), not tested above
My arch linux has by default gcc 10.2 for x64 and aarch64-linux, no arm-linux-gnueabi, only arm-none-eabi moreover, they are all v10.2. So I find it convenient to build and try. Who knows, maybe this works too? I am in middle of GCC compiling already though.
just try to compile a recent kernel-version line 5.10-main ;)
afair i had patches for gcc5 and 8 (bpi 4.4 was only compilable with gcc4)
4.4 does not really do more here
Have you managed to compile 4.4? I used a ubuntu 14.4 virtualbox last time
Sorry, it was late night so I went to sleep after building gcc. So now I have gcc-10 for aarch64(my board is a 64 bit one) and also gcc-11 for arm-linux-gueabihf . But I still need some more time, because I need to prepare the device tree, pmic driver and the clk driver from scratch. Maybe a week? Till then can you look deeper into some more clues?
Well, while working on the PMIC driver, I stumbled in a piece of information. This MT6625 is very similar in terms of working with MT7668 or MT7663. Maybe this also uses a SDIO interface? Because look, there is always 3 MSDC controllers for every MTK processors till now and two at most are used, one for eMMC and other for SDcard, the third one is present but never used. It might be possible that this Consys is also a Sdio interface? https://android.googlesource.com/platform/hardware/bsp/kernel/mediatek/mt8516-v4.4/+/refs/heads/nougat-iot-release/drivers/misc/mediatek/connectivity/wlan/gen4/ We know that connectivity here stands for the consys. And again, this same driver supports MT76XX namely MT7668 and MT7663. Albeit a new generation with gen4. MT7668 and MT7663 use SDIO 3.0/UART(BT). But it has gen3 and gen2 support also and looks like they(MT66XX) use SDIO also, maybe SDIO 3.0 with BT-SDIO instead of BT-UART? Please have a look into the driver a bit more, maybe we find something new? I was actually diving and reading datasheets from chinese sites and found all these. Some info about the chips above are also in mainline linux kernel
Imho it is a uart (serial interface),maybe sdio. Did not found anything about exact bus specifications.
But for driver/wifi-client,it looks like function mtk_wcn_wmt_func_on(WMTDRV_TYPE_WIFI) should do the real work
Nice code find,driver looks a bit better quality and gps/fm support. But as it is based on 4.4 it needs again some porting work
The drivers I pointed in the android googlesource looks a little bit cleaner to me, but it's just my opinion though, nothing serious. I mean it is a little bit less cloggy and I at least clearly know where the firmware loading code is, it is genX/common/wlan_lib.c. the definitions in genX/include/wlan_lib.h also looks like it has some useful info. I have some improvements for the MT6735 clk driver I am writing, till than can you please test if this driver is usable or not? Or at least compile-able or not? Note that this driver also supports MT6630 which is the combo chip for MT8516 and MT6630 is using SDIO interface(Source:- MT8516 technical reference manual though a simple google search about the block diagram of MT8516 will tell the same.) The gen4 part supports MT6632 and MT76XX, the SDIO chips you can find. The gen3 has the chip support we need including MT6625 parts.
Codebase is still huge and i have very limited time. I guess including it to 4.4-main should be first step,but we may need this mt7623 related code
as a first start i
added now missing include-dir (from android-code) and fixed some indentation-errors, now compile works, but i got linking-problems (i guess because of wrong MTK_PLATFORM)
link-error was because no wifi-gen was included...
currently i hang on
make[6]: *** no rule for target „drivers/misc/mediatek/connectivity/wlan/gen2/os/linux/hif/ahb//ahb_pdma.o“,
$ grep -Rni 'ahb_pdma' drivers/misc/mediatek
drivers/misc/mediatek/connectivity/wlan/gen2/Makefile:128:HIF_AHB_PDMA := $(HIF_DIR)$(MTK_PLATFORM)/
drivers/misc/mediatek/connectivity/wlan/gen2/Makefile:233:HIF_AHB_PDMA = $(HIF_DIR)mt8127/
drivers/misc/mediatek/connectivity/wlan/gen2/Makefile:237: $(HIF_AHB_PDMA)ahb_pdma.o
drivers/misc/mediatek/connectivity/wlan/gen3/Makefile:191: $(HIF_DIR)ahb_pdma.o\
As for my work, I have written half of the clk drivers and a full device tree for MT6328. After I add a full clk driver, and 3 extra LDOs for MT6328 in the MT6323 regulator, and a device tree(should be easy, will scavenge from MT8183), I can fully focus on the WiFi driver. But is some makefile statement missing for the above ahb_pdma.o file not in rule to be compiled?
I guess problem is missing mt7623 folder in $HIF_DIR,so ahb_pdma.c is not there
i se this in the Makefile:
232 ifeq ($(CONFIG_ARCH_MT7623), y) 233 HIF_AHB_PDMA = $(HIF_DIR)mt8127/ 234 endif
$(HIF_DIR) is set to os/linux/hif/ahb/ above
so problem is CONFIG_ARCH_MT7623 does not exist...i changed to CONFIG_MACH_MT7623, now error is pointing to drivers/misc/mediatek/connectivity/wlan/gen2/os/linux/hif/ahb/mt8127/ahb_pdma.o as this dir (mt8127) does not exist, i have only mt8167, but restored the folder from the old source ;)
now i get again some linker errors:
arm-linux-gnueabihf-ld: drivers/built-in.o: in function `stp_dbg_trigger_collect_ftrace':
/media/data_nvme/git/kernel/BPI-R2-4.14/drivers/misc/mediatek/connectivity/common/common_main/linux/stp_dbg.c:639: undefined reference to `aed_combo_exception_api'
arm-linux-gnueabihf-ld: /media/data_nvme/git/kernel/BPI-R2-4.14/drivers/misc/mediatek/connectivity/common/common_main/linux/stp_dbg.c:642: undefined reference to `aed_combo_exception_api'
arm-linux-gnueabihf-ld: drivers/built-in.o: in function `stp_dbg_core_dump_flush':
/media/data_nvme/git/kernel/BPI-R2-4.14/drivers/misc/mediatek/connectivity/common/common_main/linux/stp_dbg.c:509: undefined reference to `aee_kernel_dal_api'
arm-linux-gnueabihf-ld: /media/data_nvme/git/kernel/BPI-R2-4.14/drivers/misc/mediatek/connectivity/common/common_main/linux/stp_dbg.c:515: undefined reference to `aed_combo_exception_api'
arm-linux-gnueabihf-ld: drivers/built-in.o: in function `stp_dbg_core_dump_in':
/media/data_nvme/git/kernel/BPI-R2-4.14/drivers/misc/mediatek/connectivity/common/common_main/linux/stp_dbg.c:290: undefined reference to `aee_kernel_dal_api'
arm-linux-gnueabihf-ld: drivers/built-in.o: in function `osal_dbg_assert_aee':
/media/data_nvme/git/kernel/BPI-R2-4.14/drivers/misc/mediatek/connectivity/common/common_main/linux/osal.c:253: undefined reference to `aee_kernel_warning_api'
stp_* functions should are in drivers/misc/mediatek/connectivity/common/common_main/linux/stp_dbg.c (and it seems not hidden by ifdefs) and this file is included in makefile
osal_dbg_assert_aee is in drivers/misc/mediatek/connectivity/common/common_main/linux/osal.c
aee_kernel_dal_api and aee_kernel_warning_api have currently no implementation, from looking in old source, it seems we need aee folder too in root of mediatek...after adding this, it seems it fixes the others too :)
driver compilable in 4.4 :)
i wonder if we need the drivers/misc/mediatek.bak/connectivity/common/conn_soc/mt7623 from old driver
same base folder does not exist in new driver, but common_main and this does not include a $(MTK_PLATFORM) subdir
$ ls -lh drivers/misc/mediatek.bak/connectivity/common/conn_soc/mt7623
insgesamt 732K
-rw-rw-r-- 1 frank frank 226 Jun 9 20:54 built-in.a
-rw-rw-r-- 1 frank frank 325K Jun 9 20:54 built-in.o
drwxrwxr-x 2 frank frank 4,0K Jun 9 20:54 include
-rw-rw-r-- 1 frank frank 675 Jun 9 20:54 Makefile
-rw-rw-r-- 1 frank frank 0 Jun 9 20:54 modules.order
-rw-rw-r-- 1 frank frank 22K Jun 9 20:54 mtk_wcn_consys_hw.c
-rw-rw-r-- 1 frank frank 161K Jun 9 20:54 mtk_wcn_consys_hw.o
-rw-rw-r-- 1 frank frank 29K Jun 9 20:54 wmt_plat_alps.c
-rw-rw-r-- 1 frank frank 172K Jun 9 20:54 wmt_plat_alps.o
i guess it is a platform-specific implementation of the files in platform-folder
$ ls -lh drivers/misc/mediatek/connectivity/common/common_main/platform/
insgesamt 1,2M
-rw-rw-r-- 1 frank frank 498K Jun 9 20:55 built-in.o
drwxrwxr-x 2 frank frank 4,0K Jun 9 20:54 include
-rw-rw-r-- 1 frank frank 760 Jun 9 20:54 Makefile
-rw-rw-r-- 1 frank frank 0 Jun 9 20:55 modules.order
-rw-rw-r-- 1 frank frank 37K Jun 9 20:54 mt8167.c
-rw-rw-r-- 1 frank frank 12K Jun 9 20:54 mtk_wcn_cmb_hw.c
-rw-rw-r-- 1 frank frank 132K Jun 9 20:55 mtk_wcn_cmb_hw.o
-rw-rw-r-- 1 frank frank 18K Jun 9 20:54 mtk_wcn_consys_hw.c
-rw-rw-r-- 1 frank frank 150K Jun 9 20:55 mtk_wcn_consys_hw.o
-rw-rw-r-- 1 frank frank 54K Jun 9 20:54 wmt_plat_alps.c
-rw-rw-r-- 1 frank frank 227K Jun 9 20:55 wmt_plat_alps.o
-rw-rw-r-- 1 frank frank 3,9K Jun 9 20:54 wmt_plat_stub.c
as platform contains mt8167.c, i guess it is only for this chipset and i replaced it in makefile with the mt7623 folder from old driver, but it seems that there is something missing
--- a/drivers/misc/mediatek/connectivity/common/common_main/Makefile
+++ b/drivers/misc/mediatek/connectivity/common/common_main/Makefile
@@ -54,6 +54,7 @@ endif
ifeq ($(CONFIG_MTK_COMBO), y)
obj-y += core/
obj-y += linux/
-obj-y += platform/
+#obj-y += platform/
+obj-y += mt7623/
endif
I am really sorry to disturb with a bit of off topic issue. But I want to know how compatible is the mainline mediatek bluetooth driver a.k.a BTIF and btmtkuart/btmtksdio with the Banana Pi R2? is it usable at all? And what about the mainline WiFi support? The MT6625L is the RF frontend of the WiFi and bluetooth features right? Then there is an internal IP block for the BT/WiFi/ and whatnot on the board. How to get them working with mainline? Can you please point me to the right direction?