Jump to content

[Armbian build PR] - Consolidate uwe5622 driver, add v6.1 kernel support


RSS Bot

Recommended Posts

Description

The uwe5622 driver has been moved from allwinner directories into patch/misc directory with this previous pull request

With this pull request, rockchip64 family will share the base patch in misc and provides an additional, small patch to fix specific compatibility for rockchip. Ideally this minor patch would be integrated in the big driver in patch/misc, but it is not trivial task and would then require extensive tests on allwinner platform.

The pull request also provides a patch to the driver to let it compile and work on kernel v6.1, and also patches the rockchip64-edge kernel config.

At last, it fixes a memcpy fat kernel warning about field-spanning memory copy, converting the call into proper strncpy to avoid potential buffer overflows (see here)

I have removed the workaround patch for bluetooth (failed initialization) and replaced it with a quirk-based patch: the previous patch was kinda nasty because it would always say bluetooth was initialized successfully even when it wasn't, and it was configured to do so for any bluetooth driver on both allwinner and rockchip families. The new one is not ideal, but is indeed a step forward.

Some considerations:

  • drivers like uwe5622 are problematic when put in patch/misc: in this case allwinner and rockchip provide their own driver with their own changes. Their goal probably is "let the thing work on our platform". This makes hard to consolidate the changes into a single driver entity.
  • in case allwinner or rockchip will decide to publish a new updated driver that differs significantly, for the reason above, it would be quite challenging update the patches in misc;
  • provide a kernel version directory for misc patches, or at least for wifi patches? In this particular case, I had to introduce two more patches for v6.1, because some bluetooth sources and wireless interface changed, and programmatically apply them. But this makes the flow of applied patches hard to follow and even harder to tidy up in case of rebase. Maybe a git repository for such drivers and tinkering with tags and versions would help making things tidier?

Jira reference number AR-1256

How Has This Been Tested?

  • [x] Tested on OrangePi 4 LTS with current v5.15 kernel (AP association, ssh access and iperf3 tests ok)
  • [x] Tested on OrangePi 4 LTS with edge v6.1 kernel (AP association, ssh access and iperf3 tests ok)

Would be nice to test this on an allwinner board too.

Checklist:

  • [x] My code follows the style guidelines of this project
  • [x] I have performed a self-review of my own code
  • [x] I have commented my code, particularly in hard-to-understand areas
  • [x] I have made corresponding changes to the documentation
  • [x] My changes generate no new warnings
  • [x] Any dependent changes have been merged and published in downstream modules

View the full article

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines