In Linux 6.19, net_device->dev_addr is const unsigned char *.
Clang with -Werror,-Wincompatible-pointer-types-discards-qualifiers
rejects passing dev_addr to non-const parameters and memcpy into it.
Fix by:
- Replacing memcpy(dev->dev_addr, ...) with dev_addr_set()
- Using local buffer + ether_addr_copy for sprdwl_set_mac_addr call
that needs mutable addr (the function modifies it in-place)
- Changing u8 *mac pointer to u8 mac[ETH_ALEN] array in cfg80211.c
where dev_addr was assigned to a non-const pointer
Relates to #9049
From https://lore.kernel.org/all/20251230-ncm-refactor-v1-0-793e347bc7a7@google.com/
To fix slow startup, and the issue where the system fails
to release ncm devices when shutting down after plugging
or unplugging a usb hub, which references a null pointer
This is important for devices without serial ports,
such as the Elixir, because they enable NCM
by default for headless debugging,
making it easy to trigger related bugs.
Signed-off-by: CodeChenL <2540735020@qq.com>
Mainline TF-A doesn't initialize SGRF_SOC_CON8-CON15 which control
DMAC0 and DMAC1 configuration. Without this, the PL330 DMA controllers
cannot be accessed from Linux and PERIPH_ID reads as 0x0.
The fix configures SGRF registers to set DMAC manager threads to
running state and non-secure mode, then pulses DMAC reset to apply
the new configuration.
Based on community reverse-engineering:
- https://lists.denx.de/pipermail/u-boot/2023-April/514267.html
- https://gist.github.com/CrystalGamma/a68333fa4c9fda7eb6c09d30ad4937fe
Tested on Helios64 (RK3399).
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Eric submitted upstream, thanks!
- Neil RB'ed it
- `b4 am -o- --add-link --check-newer-revisions "https://lore.kernel.org/all/20260116-odroid-hc4-dts-v1-1-459b601cd5cf@linuxdev.slmail.me/" > patch/kernel/archive/meson64-6.19/board-odroid-sm1-regulators-boot-on.patch`
- Armbian's patching.py chokes on b4's "cover-below-the-fold" style, small manual fix needed before rewrite
Remove usb-role-switch property from fusb302 node and replace with
extcon property. The usb-role-switch property breaks PD negotiation
and DP alt mode on kernel 6.18+.
Fix based on PR #9245 (Pinebook Pro) by amazingfate.
Apply Helios64: fix Type-C PHY registration #9158 to 6.19.
- Fixes: 4eac206ecf which over-dropped
- meanwhile for increased insanity, patch changed name as it went upstream:
- ML was `PCI: meson: Remove meson_pcie_link_up() timeout, message, speed check`
- torvalds got `PCI: meson: Report that link is up while in ASPM L0s and L1 states`
- Greg KH has already queued for 6.18.6 (coming from 6.19-rc5, so torvalds name), so remove this when that is released
- a bit verbose but confirms missing `ethernet0`/`1` alias was the cause of random MACs for at least a few boards
- there's quite a few boards to fix, so we might want to pull this one level up later
- By fully describing the pcie hardware for the RTL8125s (rtl8169) present on the
board, we get to alias them to ethernet0/1. In return, (mainline) u-boot will by
default patch the runtime FDT though it's fdt_fixup_ethernet() implementation,
hopefully resulting in fully stable MAC addresses without the need to program
the RTL NIC's EEPROM; as an added benefit, u-boot MAC & kernel MAC would match,
facilitating network-boot setups.
Problem:
On Helios64 boot, the Type-C PHY (ff7c0000.phy) gets stuck in
"deferred probe" state with unknown reason. This causes:
- USB 3.0 SuperSpeed via Type-C port not working
- DisplayPort via Type-C (Alt Mode) not working
The following messages appear in dmesg:
platform ff7c0000.phy: deferred probe pending: (reason unknown)
platform fe800000.usb: deferred probe pending: wait for supplier /phy@ff7c0000/usb3-port
platform fec00000.dp: deferred probe pending: wait for supplier /phy@ff7c0000/dp-port
Along with dependency cycle warnings:
/phy@ff7c0000/dp-port: Fixed dependency cycle(s) with /i2c@ff3d0000/typec-portc@22/connector
Root cause:
The Helios64 DTS uses a legacy Type-C connection method:
&tcphy0 {
extcon = <&fusb0>; // Expects extcon from fusb302
};
However:
1. The FUSB302 driver with TCPM support (since kernel ~4.14) does NOT
create extcon devices
2. Instead, it uses the Type-C connector class (/sys/class/typec/)
3. The phy-rockchip-typec driver calls extcon_get_edev_by_phandle(),
fails to find an extcon device at the specified phandle, and
returns -EPROBE_DEFER
4. The PHY remains in deferred probe indefinitely
The extcon-cables property is present in the DTS, but without a
typec_extcon_bridge node it serves no purpose.
This bug has existed since Type-C support was added to Helios64
(at least since kernel 6.6). It likely worked with older fusb302
driver versions, but broke after the transition to TCPM.
Solution:
Use the typec-extcon-bridge driver (Armbian patch from Ondrej Jirman/megi)
which translates Type-C connector class events to the extcon interface.
The Pinebook Pro patch (board-pbp-add-dp-alt-mode.patch) implements this
correctly: it has a typec_extcon_bridge node, and all extcon references
point to it rather than directly to fusb0.
Changes:
1. Add typec_extcon_bridge node with compatible = "linux,typec-extcon-bridge"
2. Change extcon = <&fusb0> to extcon = <&typec_extcon_bridge> in
tcphy0, cdn_dp, u2phy0, usbdrd_dwc3_0 nodes
3. Add usb-role-switch, mode-switch, orientation-switch properties
to fusb0 connector for integration with the bridge
4. Update PDO definitions with DUAL_ROLE and DATA_SWAP flags
5. Convert typec-altmodes property to modern altmodes subnode format
(required for TCPM port registration)
6. Add extcon,ignore-usb to u2phy0 (following Pinebook Pro pattern)
7. Add snps,usb3-phy-reset-quirk to usbdrd_dwc3_0
After this fix:
- Type-C PHY (ff7c0000.phy) no longer stuck in deferred probe
- USB 3.0 SuperSpeed via Type-C port should work
- DisplayPort via Type-C (Alt Mode) should work
- Correct cable orientation detection
- USB role switching (host/device)
Known remaining issues:
- FUSB302 fails to register TCPM port with error:
4-0022 typec_fusb302: cannot register tcpm port
This prevents USB Power Delivery negotiation. The root cause
appears to be in the connector configuration and requires
further investigation.
- move patches into version folder (`atf-rockchip` -> `atf-rockchip/v2.13`)
- also prepares patches for v2.14 since I had them anyway
- keeps using v2.13 for now, someone can test v2.14 later and bump; I've no rk3399
- new patches:
- add `-no-pie` to rk3399's m0 build LDFLAGS (since upstream doesn't honor M0_LDFLAGS)
- bump PMSURAM_RSIZE from 8k to 16k to avoid overflows - confirmed working by Amazingfate
- build tested OK on jammy/bookworm/trixie/noble/resolute
- resolute's gcc 15 and it still builds
- now each arch has its own dt folder, with its own Makefile auto-patched
- simple Makefile autopatching with `add-only: true`
- as example convert 01 null-patch to bare-dt in `dt_32/` (drop from series too)
- this patches u-boot default addresses with the same values used in the boot-genio bootscript
- this enables booting extlinux with large kernels and initrd (eg: `EXT=u-boot-menu`)
- backport fixes from upstream u-boot for
- BTRFS (plus enable BTRFS and BZIP2 support for radxa-nio-12l)
- tested with `CARD_DEVICE=/dev/mmcblk1 ROOTFS_TYPE=btrfs BTRFS_COMPRESSION=zstd` (no UFS!)
- also with `EXT=ufs CARD_DEVICE=/dev/sdc ROOTFS_TYPE=btrfs BTRFS_COMPRESSION=zstd` (UFS!)
- 4k block size UFS for UMS: fixes block size issue (USB issues unhandled)
- Enable "bind" command for the Mediatek-standard USB Gadget Ethernet
- this way, one doesn't need to cripple UFS to be able to boot from SD
- USB didn't get the same treatment as it's slow and **not working**...
- ...and beyond me to fix; both OTG and Host mode are funky in u-boot...
- ...but seem to work fine in kernel
- IMPORTANT: keep in mind: "SDcard is NOT UFS (4k block)" and don't fall for traps!
- Network note:
- `setenv ethaddr xx:xx:xx:xx:xx:xx` & `saveenv` & `reset`
- required for network booting; mtk doesn't use random/cpu# MAC
- required for stable MAC in kernel (keep IP from changing, etc)
