Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lantiq: add 6.1 testing support #15233

Merged
merged 21 commits into from May 15, 2024
Merged

Conversation

sch-m
Copy link
Contributor

@sch-m sch-m commented Apr 22, 2024

@PolynomialDivision This is the continuation of #13046.

What I've done in addition to @hauke's work:

  • refreshed all kernel configs and patches for 5.15 and 6.1 once again
  • extended the PCIe and GPTU drivers so that they fetch the IRQs from the DeviceTree and as a result eliminated the HACK patch
  • removed the last 4 GSWIP patches from the patchset for now due to the resulting functionality issues. The driver needs to be looked at again independently of the linux update.
  • fix/work around the problem with the warning regarding field-spanning write in the DSL MEI driver.
  • extended the drivers ltq-atm, ltq-ptm, ltq-adsl-mei and ltq-vmmc to fetch the IRQs from the DeviceTree.
  • performed tests with xrx200 (VRX268; no voice).

@sch-m sch-m mentioned this pull request Apr 22, 2024
42 tasks
@github-actions github-actions bot added kernel pull request/issue with Linux kernel related changes target/lantiq pull request/issue for lantiq target core packages pull request/issue for core (in-tree) packages labels Apr 22, 2024
@mrkiko
Copy link
Contributor

mrkiko commented Apr 22, 2024

Are some of these changes applicable to VRX518 DSL driver?
I can see the field-spanning write in drv_mei_cpe_msg_process.c:3570 in FRITZ!BOX 7530.

@sch-m
Copy link
Contributor Author

sch-m commented Apr 22, 2024

Are some of these changes applicable to VRX518 DSL driver? I can see the field-spanning write in drv_mei_cpe_msg_process.c:3570 in FRITZ!BOX 7530.

You can port this change to the ltq-vdsl-vr11-mei driver or maybe find a cleaner solution: 392b84a

@sch-m sch-m force-pushed the pr/20240411-lantiq-6.1 branch 2 times, most recently from 368a7a2 to a02f4b3 Compare April 29, 2024 05:41
@sch-m
Copy link
Contributor Author

sch-m commented Apr 29, 2024

@PolynomialDivision What can I do to get this PR accepted?

@abajk
Copy link
Contributor

abajk commented Apr 29, 2024

Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> # Tested on AVM 5490 (Ethernet, USB)
Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> # Tested on AVM 7330 (Ethernet, USB, WiFi)

target/linux/lantiq/ase/config-5.15 Show resolved Hide resolved
target/linux/lantiq/ase/config-6.1 Show resolved Hide resolved
@PolynomialDivision
Copy link
Member

Did you send some of the kernel patches upstream?

@abajk
Copy link
Contributor

abajk commented May 1, 2024

WiFi does not work on the AVM 7320 with the new kernel.
6.1 -> https://pastebin.com/nAtrbSgL
5.15 -> https://pastebin.com/QL7GW7bs

The image is exactly the same. Only the kernel version differs.
USB and Ethernet work the same as on 5.15. Unfortunately, I have no way to test the ADSL2+ part.

In the next step, I plan to do tests on the BT Home Hub5A and see if WiFi on the PCI bus works there.

@nouman8
Copy link

nouman8 commented May 1, 2024

wifi and vdsl2 work on bt-hh5a i have tested.

@sch-m
Copy link
Contributor Author

sch-m commented May 1, 2024

Did you send some of the kernel patches upstream?

Do you mean the gswip patches? No, I didn't so far, but I also would like to have this changes upstream in the kernel.
I am not the author of this changes, but as @hauke and @xdarklight already discussed in #13200 (comment) he seems to be fine when someone else trys to send them upstream.

@sch-m
Copy link
Contributor Author

sch-m commented May 1, 2024

WiFi does not work on the AVM 7320 with the new kernel.

Is the PCI bus working with linux 6.1? What's the output of lspci?
Is the ath9k driver loaded?

@sch-m
Copy link
Contributor Author

sch-m commented May 1, 2024

WiFi does not work on the AVM 7320 with the new kernel.

Is the PCI bus working with linux 6.1? What's the output of lspci? Is the ath9k driver loaded?

Ah, I overlooked the output of lspci at the top of your log. Well, then there seems to be a problem in the PCI bus driver.

@sch-m
Copy link
Contributor Author

sch-m commented May 1, 2024

Could you please show me the output of cat /proc/interrupts with 5.15 and 6.1 running on the AVM 7320?

@sch-m
Copy link
Contributor Author

sch-m commented May 2, 2024

wifi and vdsl2 work on bt-hh5a i have tested.

Also interesting that the wifi works on the bt-hh5a. According to dts, there is also an ath9k connected via PCI.

@abajk
Copy link
Contributor

abajk commented May 2, 2024

Could you please show me the output of cat /proc/interrupts with 5.15 and 6.1 running on the AVM 7320?

A freshly installed image without keeping the configuration:

root@OpenWrt:/# uname -a
Linux OpenWrt 5.15.155 #0 SMP Wed May 1 09:17:24 2024 mips GNU/Linux
root@OpenWrt:/# cat /proc/interrupts 
           CPU0       CPU1       
  7:    8450694    8421272      MIPS   7  timer
  8:     107991     403379      MIPS   0  IPI call
  9:       1812       1604      MIPS   1  IPI resched
 30:          0          0       icu  30  ath9k
 62:          0          0       icu  62  1e101000.usb, dwc2_hsotg:usb1
 63:     256664          0       icu  63  DFEIR
 72:       2208          0       icu  72  eth_rx
 73:       3809          0       icu  73  eth_tx
 91:          0          0       icu  91  1e106000.usb, dwc2_hsotg:usb2
112:       1563          0       icu 112  asc_tx
113:        121          0       icu 113  asc_rx
114:          0          0       icu 114  asc_err
126:          0          0       icu 126  gptu
127:          0          0       icu 127  gptu
128:          0          0       icu 128  gptu
129:          0          0       icu 129  gptu
130:          0          0       icu 130  gptu
131:          0          0       icu 131  gptu
ERR:          1
root@OpenWrt:/# uname -a
Linux OpenWrt 6.1.89 #0 SMP Wed May  1 09:17:24 2024 mips GNU/Linux
root@OpenWrt:/# cat /proc/interrupts 
           CPU0       CPU1       
  7:      13149      12759      MIPS   7  timer
  8:       1919       7495      MIPS   0  IPI call
  9:       1012        897      MIPS   1  IPI resched
 62:          0          0       icu  62  1e101000.usb, dwc2_hsotg:usb1
 63:        142          0       icu  63  DFEIR
 72:        514          0       icu  72  eth_rx
 73:        853          0       icu  73  eth_tx
 91:          0          0       icu  91  1e106000.usb, dwc2_hsotg:usb2
112:        357          0       icu 112  asc_tx
113:         45          0       icu 113  asc_rx
114:          0          0       icu 114  asc_err
126:          0          0       icu 126  gptu
127:          0          0       icu 127  gptu
128:          0          0       icu 128  gptu
129:          0          0       icu 129  gptu
130:          0          0       icu 130  gptu
131:          0          0       icu 131  gptu
ERR:          1

@PolynomialDivision
Copy link
Member

@sch-m please send the fixes upstream and backport the patch send upstream. It would be nice even for the patches you keep downstream to write a complete patch header. That makes it easier to directly know what a patch is about in the future. We have also now a kernel bumper script. You could also use that to preserve history. Otherwise I think the changes are fine. Thanks a lot for your work.

@sch-m
Copy link
Contributor Author

sch-m commented May 2, 2024

@abajk Maybe we have a problem with this change in 6.1:

torvalds/linux@90c2d2e

This reversed the active-low/high logic of the reset GPIO, didn't it?

@abajk
Copy link
Contributor

abajk commented May 2, 2024

@abajk Maybe we have a problem with this change in 6.1:

torvalds/linux@90c2d2e

This reversed the active-low/high logic of the reset GPIO, didn't it?

Reverting this change fixes the wifi on the router. I wonder why pci works on some devices and how we can identify them.

EDIT: Maybe the reset gpio for some devices are incorrectly described in dts.

@sch-m
Copy link
Contributor Author

sch-m commented May 2, 2024

According to the specification, PCI RST# is an active low signal. However, in all the related DTS the reset-gpio is defined as active high and the driver has reversed the logic internally up to linux 6.0.

So in my opinion it would actually be correct to change the gpio to active low in the DTS files.

@sch-m
Copy link
Contributor Author

sch-m commented May 3, 2024

I've added a commit to invert the pci gpio-reset polarity in the dts files.

@abajk @nouman8
Can you please test again on your boards if the wifi works.

@abajk
Copy link
Contributor

abajk commented May 3, 2024

@abajk @nouman8 Can you please test again on your boards if the wifi works.

Unfortunately, it seems that wifi still does not work (logs).

@abajk
Copy link
Contributor

abajk commented May 3, 2024

During the upgrade, a trace log also appears:

root@OpenWrt:/tmp# sysupgrade -n openwrt-lantiq-xway-avm_fritz7320-squashfs-sysu
pgrade.bin 
Fri May  3 07:21:27 UTC 2024 upgrade: Commencing upgrade. Closing all shell sessions.
[  653.152811] do_page_fault(): sending SIGSEGV to dnsmasq for invalid read access from 77d6906d
[  653.160158] epc = 77e1f100 in ld-musl-mips-sf.so.1[77ded000+b2000]
[  653.166018] ra  = 77e1f6a4 in ld-musl-mips-sf.so.1[77ded000+b2000]
Watchdog handover: fd=3
- watchdog -
Watchdog did not previously reset the system
Fri May  3 07:21:30 UTC 2024 upgrade: Sending TERM to remaining processes ...
Fri May  3 07:21:30 UTC 2024 upgrade: Sending signal TERM to dsl_cpe_control (2514)
Fri May  3 07:21:34 UTC 2024 upgrade: Sending KILL to remaining processes ...
Fri May  3 07:21:34 UTC 2024 upgrade: Sending signal KILL to dsl_cpe_control (2514)
[  667.034201] stage2 (2730): drop_caches: 3
Fri May  3 07:21:43 UTC 2024 upgrade: Switching to ramdisk...
mount: mounting /dev/mtdblock4 on /overlay failed: Resource busy
[  673.615592] ------------[ cut here ]------------
[  673.618891] WARNING: CPU: 1 PID: 2730 at fs/super.c:503 generic_shutdown_super+0x158/0x198
[  673.627056] VFS: Busy inodes after unmount of jffs2 (jffs2)
[  673.627093] Modules linked in: ath9k ath9k_common nft_fib_inet nf_flow_table_inet ath9k_hw ath pppoe nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_                                                                                                                                                                                                            c
[  673.706066] CPU: 1 PID: 2730 Comm: busybox Not tainted 6.1.89 #0
[  673.711925] Stack : 00000000 80085a14 00000000 00000004 00000000 00000000 83e9bd1c 80a40000
[  673.720206]         80910000 807a8334 80f657d0 80910873 00000000 00000001 83e9bcc8 80c3c800
[  673.728484]         00000000 00000000 807a8334 83e9bbf0 ffffefff 00000000 00000000 ffffffea
[  673.736757]         000000c7 83e9bbfc 000000c7 80890638 807a8334 00000001 83e9bdc8 801d6660
[  673.745049]         00000009 807b0f58 80888258 7f71d870 00000018 00000030 00000004 80a40004
[  673.753328]         ...
[  673.755736] Call Trace:
[  673.758162] [<8000c5ec>] show_stack+0x28/0xf0
[  673.762470] [<806bf578>] dump_stack_lvl+0x60/0x80
[  673.767137] [<80030e10>] __warn+0xb0/0xe4
[  673.771092] [<80030fc4>] warn_slowpath_fmt+0x180/0x188
[  673.776182] [<801d6660>] generic_shutdown_super+0x158/0x198
[  673.781721] [<80432c34>] kill_mtd_super+0x14/0x30
[  673.786361] [<802759ec>] jffs2_kill_sb+0x5c/0x74
[  673.790946] [<801d60f8>] deactivate_locked_super+0x4c/0xbc
[  673.796367] [<801fe638>] cleanup_mnt+0xb0/0x15c
[  673.800870] [<80050e30>] task_work_run+0x94/0xd8
[  673.805425] [<8000bb3c>] do_notify_resume+0x214/0x248
[  673.810446] [<80007690>] work_notifysig+0x10/0x18
[  673.815088] 
[  673.816676] ---[ end trace 0000000000000000 ]---
Fri May  3 07:21:50 UTC 2024 upgrade: Performing system upgrade...
[  673.999026] do_stage2 (2730): drop_caches: 3
Unlocking firmware ...

Writing from <stdin> to firmware ...     
Fri May  3 07:22:49 UTC 2024 upgrade: Upgrade completed
Fri May  3 07:22:50 UTC 2024 upgrade: Rebooting system...
umount: can't unmount /dev: Resource busy
[  734.781170] reboot: Re�
ROM VER: 1.1.3

It was not present on the 5.15 kernel.

@nouman8
Copy link

nouman8 commented May 3, 2024

tested with the new "dts Invert" commit on bt-hh5a both ath9k and ath10k wireless are working

@sch-m
Copy link
Contributor Author

sch-m commented May 6, 2024

Unfortunately, it seems that wifi still does not work (logs).

Well, I think the remaining problem is that the new code in the lantiq-pci driver initializes the GPIO in LOW state (independently of the ACTIVE-LOW/HIGH flag in the dts), whereas the former driver code has set it to HIGH state.

So maybe the best would be to keep the dts files unchanged and patch the driver once again to restore the old behavior but use the newer gpiod API.

sch-m and others added 19 commits May 15, 2024 08:54
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.

For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Add KERNEL_TESTING_PATCHVER for Linux 6.1.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Make all the patches apply and delete the ones already integrated into
upstream Linux kernel. This also refreshes some of the kernel
configurations.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
[refreshed for linux 6.1.89]
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This makes the components used on the lantiq SoCs compile with kernel
6.1.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
[also fix ifxmips_ptm_adsl.c]
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
If the reverted timer driver fails to allocate interrupts handle the
error better.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
[moved printk before the cleanup for-loop]
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This backports some patches for the gswip switch driver.

I copied them from this repository:
https://github.com/xdarklight/linux/commits/lantiq-gswip-integration-20221022

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
[drop some patches which may break functionality at the moment]
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Use dev_err_probe() to get rid of the following warning which is
seen when the PCIe PHY has not been probed yet:
pcie-xrx200 1d900000.pcie: failed to get the PCIe PHY

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This adds the missing interrupts to the pcie node.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This is required for linux-6.1 compatibility.

IRQs are not automatically mapped from HW to virtual IRQ numbers when
the IRQ domain is registered. This happens when the IRQ number is read
from the device tree based on the IRQ domain from the device tree now.
In kernel 5.15 it was done when the IRQ domain was registered.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This is required for linux-6.1 compatibility.

IRQs are not automatically mapped from HW to virtual IRQ numbers when
the IRQ domain is registered. This happens when the IRQ number is read
from the device tree based on the IRQ domain from the device tree now.
In kernel 5.15 it was done when the IRQ domain was registered.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
We need to use unsafe_memcpy() here, because the code do the field-
spanning write intentionally.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This is required for linux-6.1 compatibility.

IRQs are not automatically mapped from HW to virtual IRQ numbers when
the IRQ domain is registered. This happens when the IRQ number is read
from the device tree based on the IRQ domain from the device tree now.
In kernel 5.15 it was done when the IRQ domain was registered.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This is required for linux-6.1 compatibility.

IRQs are not automatically mapped from HW to virtual IRQ numbers when
the IRQ domain is registered. This happens when the IRQ number is read
from the device tree based on the IRQ domain from the device tree now.
In kernel 5.15 it was done when the IRQ domain was registered.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This fixes the write beyond size of field compile warning/error.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This is required for linux-6.1 compatibility.

IRQs are not automatically mapped from HW to virtual IRQ numbers when
the IRQ domain is registered. This happens when the IRQ number is read
from the device tree based on the IRQ domain from the device tree now.
In kernel 5.15 it was done when the IRQ domain was registered.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Let's get the IRQs from the kernel-in-tree vmmc driver like it is
already done for the cp1 base addr.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This adds to missing DyingGasp and USB OC interrupts to the mei node.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This is required for linux-6.1 compatibility.

IRQs are not automatically mapped from HW to virtual IRQ numbers when
the IRQ domain is registered. This happens when the IRQ number is read
from the device tree based on the IRQ domain from the device tree now.
In kernel 5.15 it was done when the IRQ domain was registered.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Linux kernel commit 90c2d2eb7ab5 ("MIPS: pci: lantiq: switch to using
gpiod API") not only switched to the gpiod API, but also inverted /
changed the polarity of the GPIO.

According to the PCI specification, the RST# pin is an active-low
signal. However, most of the device trees that have been widely used for
a long time (mainly in the openWrt project) define this GPIO as
active-high and the old driver code inverted the signal internally.

Apparently there are actually boards where the reset gpio must be
operated inverted. For this reason, we cannot use the GPIOD_OUT_LOW/HIGH
flag for initialization. Instead, we must explicitly set the gpio to
value 1 in order to take into account any "GPIO_ACTIVE_LOW" flag that
may have been set.

In order to remain compatible with all these existing device trees, we
should therefore keep the logic as it was before the commit.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
@openwrt-bot openwrt-bot merged commit cffd3ad into openwrt:main May 15, 2024
150 checks passed
@PolynomialDivision
Copy link
Member

PolynomialDivision commented May 15, 2024

@sch-m Thanks a lot! Merged. Can you maybe proceed with 6.6 support? :)

@sch-m sch-m deleted the pr/20240411-lantiq-6.1 branch May 15, 2024 08:30
@sch-m
Copy link
Contributor Author

sch-m commented May 15, 2024

@sch-m Thanks a lot! Merged. Can you maybe proceed with 6.6 support? :)

I'm already on it.

@Neustradamus
Copy link

@sch-m: Good job!

@dhewg
Copy link
Contributor

dhewg commented May 24, 2024

Are some of these changes applicable to VRX518 DSL driver? I can see the field-spanning write in drv_mei_cpe_msg_process.c:3570 in FRITZ!BOX 7530.

You can port this change to the ltq-vdsl-vr11-mei driver or maybe find a cleaner solution: 392b84a

Any update on this, or was this patch lost? I'd be nice to fix this warning for both vr9 and vr11 at the same time

@sch-m
Copy link
Contributor Author

sch-m commented May 27, 2024

Any update on this, or was this patch lost? I'd be nice to fix this warning for both vr9 and vr11 at the same time

Since this patch set was only lantiq related, I only patched the ltq-vdsl-vr9-mei package. But I can also create a PR for ltq-vdsl-vr11-mei.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core packages pull request/issue for core (in-tree) packages kernel pull request/issue with Linux kernel related changes target/lantiq pull request/issue for lantiq target
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants