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.

Sign up for GitHub

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

Jump to bottom

[RFC/WIP]: armsr: add 6.6 as testing kernel #14896

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

[RFC/WIP]: armsr: add 6.6 as testing kernel #14896

wants to merge 8 commits into from
+1,345 −8

Conversation

mcbridematt
Copy link
Contributor

@mcbridematt mcbridematt commented Mar 15, 2024 •
edited

This patch set adds kernel 6.6 as the testing version for the armsr target.

Notes:

  • kmod-drm is broken, while CONFIG_DRM_EXEC and CONFIG_DRM_SUBALLOC_HELPER are specified, the kernel doesn't build them (due to lack of modules depending on them?)
  • The GPIO numbers shifted as a result of changes in kernel 6.2, I think there will need to be an OpenWrt-wide approach to handle this
  • armsr_armv8 requires virto_virqfd to be flagged as for 6.2 and earlier (same as x86, see x86: add 6.6 as testing kernel #14868 (comment))
  • Only tested so far in QEMU (armv7 and armv8) and Traverse Technologies Ten64. I will try some other hosts (e.g AWS Graviton) next week for armv8

@mcbridematt mcbridematt marked this pull request as draft March 15, 2024 05:43
@github-actions github-actions bot added kernel pull request/issue with Linux kernel related changes core packages pull request/issue for core (in-tree) packages target/armsr pull request/issue for armsr target labels Mar 15, 2024
@namiltd
Copy link
Contributor

namiltd commented Mar 15, 2024

4a2138c Missing commit message. Please describe your changes

@hackpascal
Copy link
Contributor

  • kmod-drm is broken, while CONFIG_DRM_EXEC and CONFIG_DRM_SUBALLOC_HELPER are specified, the kernel doesn't build them (due to lack of modules depending on them?)

This has been fixed by #14899

ehem
ehem suggested changes Mar 16, 2024
View reviewed changes
Copy link
Contributor

@ehem ehem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a script for this which preserves history, that should be used instead.

(note to committers, the results of that script cannot be directly rebased)

@john-tho
Copy link
Contributor

  • The GPIO numbers shifted as a result of changes in kernel 6.2, I think there will need to be an OpenWrt-wide approach to handle this

Maybe worth taking this to the mailing list, or pinging some maintainers to get the discussion going.

A quick and (very) dirty hack could be to modify the gpio_switch script (and config setter) to accept strings, which then could be greped against gpio-line-names or DTS labels in cat /sys/kernel/debug/gpio.
Maybe better is a gpiolib based solution?

You would also need a migration script to update these details in stored config if a sysupgrade takes a device from 6.1 to 6.6?

@mcbridematt
Copy link
Contributor Author

mcbridematt commented Mar 18, 2024 •
edited

There is a script for this which preserves history, that should be used instead.

(note to committers, the results of that script cannot be directly rebased)

Done, the new commits are based on that

Maybe worth taking this to the mailing list, or pinging some maintainers to get the discussion going.

I'll post to the ML. I can find some discussion about it back in 2022 but it appears further movement was waiting on libgpiod v2 to come out (which it did, last August).

I have tried to detect the kernel version and choose the correct GPIO base numbers that way, but I don't like this 100% either.

I would prefer using sysfs paths (like /sys/devices/platform/soc/2000000.i2c/i2c-0/0-0076/gpio/) but the problem is that board.d is run before modules, so it may not always find GPIOs from drivers that are not built into the kernel.

gpio-line-names from DT could be an option, but for a "universal" target like armsr, we can't depend on every board having a DTB that is setup correctly for us.

edit: Posted here http://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042448.html

@mcbridematt
kernel/armsr: Add configuration files and patches for v6.6
48b545f 
Based on the 6.1 files, but without any 6.6 additions.

Signed-off-by: Mathew McBride <matt@traverse.com.au>
@mcbridematt
kernel/armsr: Restore kernel files for v6.1
08ca9b7 
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.

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

Signed-off-by: Mathew McBride <matt@traverse.com.au>
@mcbridematt
kernel/armsr: add config stubs and changes needed for 6.6
cc1fd4a 
Introduce new configuration options prompted by 6.6 (relative to 6.1).
The kernel arm64 defconfig is used as guide for 'core' options, while
video/camera/other media drivers are turned off by default.

Signed-off-by: Mathew McBride <matt@traverse.com.au>
@mcbridematt
armsr: add kernel 6.6 as a testing target
2accf22 
Add kernel 6.6 for testing.

Signed-off-by: Mathew McBride <matt@traverse.com.au>
@mcbridematt
kernel: vfio: flag vfio_virqfd as only kernel 6.2 and earlier
406fa54 
Kernel 6.2 folded virqfd (eventd interface for VFIO interrupts)
into the base vfio module, it is no longer a tristate option.

Change suggested by vincejv on GitHub:
openwrt#14868 (comment)

Signed-off-by: Mathew McBride <matt@traverse.com.au>
@mcbridematt
armsr: armv8: add new fsl-enetc-core module for kernel 6.6
7c5e516 
From kernel 6.3 onwards, the fsl-enetc driver has restructured
it's common code into a 'core' module[1].

Signed-off-by: Mathew McBride <matt@traverse.com.au>

[1] https://patchwork.kernel.org/project/netdevbpf/patch/20230119160431.295833-2-vladimir.oltean@nxp.com/
@mcbridematt
base-files: armsr: number Ten64 GPIOs according to kernel version
18800ca 
A change in kernel 6.2[1] caused the base numbers of GPIOs to
change significantly on some architectures like aarch64.

We have to number our GPIOs accordingly.
Ideally the board.d scripts should look through sysfs
to find the basenum (like cat "/sys/devices/platform/soc/2000000.i2c/
i2c-0/0-0076/gpio/gpiochip640/base"), but the problem is
that this occurs before modules are loaded, meaning I2C and other
runtime devices may be missing.

Signed-off-by: Mathew McBride <matt@traverse.com.au>

[1] https://lore.kernel.org/lkml/cover.1662116601.git.christophe.leroy@csgroup.eu/T/
@mcbridematt
base-files: armsr: add script to migrate GPIO switches on Ten64 board
47a7d0a 
Due to a change in kernel 6.2, the GPIO numbers on certain
architectures (including arm64) have changed. This script
will update any defined GPIO switches to the new numbering.

See https://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042448.html
for more information.

In the future, the GPIO switch mechanism will likely be
replaced with something using libgpiod.

Signed-off-by: Mathew McBride <matt@traverse.com.au>
@mcbridematt mcbridematt marked this pull request as ready for review April 2, 2024 07:37
@mcbridematt
Copy link
Contributor Author

Rebased and tested working on various AWS Graviton instances (a1.metal,c6g.metal,t4.nano)
It doesn't look like there will be a change in the GPIO system just yet, so a uci-defaults script will update existing gpio_switch references where needed.

@sanderpqr sanderpqr mentioned this pull request Apr 3, 2024
Merged
@namiltd namiltd mentioned this pull request Apr 17, 2024
Open
39 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ehem ehem ehem requested changes

At least 6 approving reviews are required to merge this pull request.

Assignees
No one assigned
Labels
core packages pull request/issue for core (in-tree) packages kernel pull request/issue with Linux kernel related changes target/armsr pull request/issue for armsr target
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
5 participants
@mcbridematt @namiltd @hackpascal @john-tho @ehem