bes2600 driver

[Kevin Kofler]

I would try applying the patch with patch -p1 <  instead of git apply.

[explit]

I would try applying the patch with patch -p1 <  instead of git apply.

Thanks for the info. I tried that and this is what i got:

[explit@PineTab2 linux-pinetab2]$ patch -p1 < ../0001-Add-wake-for-WiFi.patch
patching file arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
Hunk #1 succeeded at 162 with fuzz 2 (offset 5 lines).
Hunk #2 succeeded at 180 (offset -96 lines).
Hunk #3 succeeded at 780 with fuzz 2 (offset -76 lines).
Hunk #4 FAILED at 935.
1 out of 4 hunks FAILED -- saving rejects to file arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi.rej

[Kevin Kofler]

So then the idea would be to look at the .rej file, try to figure out why that hunk failed, and do the modifications manually.

Or you could try increasing the fuzz (passing -F3 to patch in addition to the other parameters), but it is probably a bad idea since context is important for .dtsi files. Better check the .rej file by hand.

Hunk 4 is a 1-line patch. It should not be too hard to make the change by hand.

[explit]

So then the idea would be to look at the .rej file, try to figure out why that hunk failed, and do the modifications manually.

Or you could try increasing the fuzz (passing -F3 to patch in addition to the other parameters), but it is probably a bad idea since context is important for .dtsi files. Better check the .rej file by hand.

Hunk 4 is a 1-line patch. It should not be too hard to make the change by hand.

Thanks for the Info. Here is the content of the
.rej file

Code:

--- arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
+++ arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
@@ -935,7 +949,7 @@ &sdmmc1 {
        cap-sd-highspeed;
        cap-sdio-irq;
        keep-power-in-suspend;
+       mmc-pwrseq = <&sdio_pwrseq &sdio_pwrkey>;
        non-removable;
        pinctrl-names = "default";
        pinctrl-0 = <&sdmmc1_bus4
--

This is the patch:
https://gitlab.com/arjanvlek/bes2600/-/b...type=heads

And this is the file, that should be patched:
https://github.com/dreemurrs-embedded/li...etab2.dtsi

As i understand, the line, which should be patched, doesn't exist in the rk3566-pinetab2.dtsi file.

I am not very familiar with patch, so if you can point me to the right direction - that would be great!

Thanks

[Kevin Kofler]

Try applying the attached patch:

  rk3566-pinetab2.dtsi-readd-wifi.patch.txt (Size: 1.79 KB / Downloads: 109)
before 0001-Add-wake-for-WiFi.patch. (You should apply both patches, mine first, then the other one.) My patch readds some WiFi-related blocks that were removed between v6.5.5-danctnix1 and v6.5.6-danctnix1.

Be warned that I do not know why those blocks were removed and that I have not tested the patches in any way. All I know is that the absence of those blocks is what makes the patch fail to apply, and I can only guess that the WiFi driver wants those blocks anyway, but as I said, I have not found any documentation on why they were removed. (There is not even a commit removing them. The commit adding the .dtsi was just redone without those blocks. So there is no history in which to check the commit messages.)

[explit]

Thanks for the patch. I tried it. Your patch succeeded, the other one failed again on Hunk4
[explit@PineTab2 linux-pinetab2]$ patch -p1 < ../0000-Readd-Wifi_Patch.patch
patching file arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
Hunk #2 succeeded at 267 (offset 11 lines).
Hunk #3 succeeded at 857 (offset 14 lines).
Hunk #4 succeeded at 932 (offset 14 lines).
[explit@PineTab2 linux-pinetab2]$ patch -p1 < ../0001-Add-wake-for-WiFi.patch
patching file arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
Hunk #1 succeeded at 154 (offset -3 lines).
Hunk #2 succeeded at 284 (offset 8 lines).
Hunk #3 succeeded at 867 (offset 11 lines).
Hunk #4 FAILED at 935.
1 out of 4 hunks FAILED -- saving rejects to file arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi.rej


[explit@PineTab2 linux-pinetab2]$ cat arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi.rej
--- arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
+++ arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
@@ -935,7 +949,7 @@ &sdmmc1 {
cap-sd-highspeed;
cap-sdio-irq;
keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq &sdio_pwrkey>;
non-removable;
pinctrl-names = "default";
pinctrl-0 = <&sdmmc1_bus4
--

[Kevin Kofler]

You must be using a wrong version of the 0001 patch. I tried applying the one you linked to: https://gitlab.com/arjanvlek/bes2600/-/b...type=heads and it applies just fine to the file from v6.5.7-danctnix1 patched with my patch.

[explit]

You must be using a wrong version of the 0001 patch. I tried applying the one you linked to: https://gitlab.com/arjanvlek/bes2600/-/b...type=heads and it applies just fine to the file from v6.5.7-danctnix1 patched with my patch.

You are absolutely right, sorry, my mistake. Somehow my patch was broken. Thank you very much, now it worked!

[genobraker]

I just redid the procedure accordingly on mobian and it worked flawlessly.

Code:

root@mobian:~# uname -a
Linux mobian 6.6-rockchip #1 SMP PREEMPT_DYNAMIC Mon Oct 30 09:10:41 UTC 2023 aarch64 GNU/Linux
root@mobian:~# lsmod | grep bes
bes2600               253952  0
mac80211              888832  1 bes2600
cfg80211              835584  2 bes2600,mac80211

Wifi speed is the same as on arch. And on mobian it did not even hang on shutdown, i.e. clean shutdown. I am keeping my fingers crossed this is persistent and if so, I will surely include the module in the proper kernel module locations to be loaded normally during boot.

I wrote down a few notes on the differences to arch. I will prepare a MR on https://gitlab.com/arjanvlek/bes2600/-/b.../README.md with the Debian infrastructure approach to this. Like deb-src packages.

Hi, I'm interested for mobian. At the part clone "1.3 Setup kernel...-" which repository you cloned and what kernel did you use? Outside of these, the steps are same, i guess

[explit]

Very interesting fact is, that every new boot, the bes2600 driver generate a new MAC-Address.
This is bad, because i have MAC-WhiteLists in my Router.

Hm, is this possible to force the driver use only one MAC-Address?