fh8856: fix JL1101 PHY detection, PHY reset GPIO and SD1 pinctrl on V100 boards

[kasperiio]

Three fixes for the FH8856 (V100) as found on the Vatilon PB1 / Asecam board, on top of fullhan-fh8852v100.

1. fh_gmac: recognise the JLSemi JL1101 PHY id 0x937c4024 — a newer stepping of the JL1101 the driver already knows as 0x937c4023; same RMII setup. Without it the PHY is not recognised and eth0 never links.

2. fh8856: do not pulse the (unwired) PHY reset GPIO — CONFIG_GPIO_EMACPHY_RESET maps to pad 46, which is PWM7 on this board and not connected to the PHY. Toggling it during boot left the JL1101 dead on MDIO (no PHY found, no network). U-Boot has already configured the PHY, and the vendor kernel never resets it either.

3. fh8856: drop SD1_NO_WP from the default pinctrl selection — muxing the SD1 pads at boot hangs the SoC on this board, which has no SD1 slot and uses those pads for other functions (the pad-51 GPIO16 path is where fh_pinctrl_init_devices() stalls). No supported FH8856 target uses SD1.

Verification

Built through the OpenIPC firmware tree (fh8856v100_lite) with the kernel fetched from this branch and only the tree-wide gcc-compatibility patches applied — no per-board patches — and booted on the board from RAM against a flashed OpenIPC rootfs: eth0 links, udhcpc runs, the streamer starts, login prompt reached, no oops. The same three changes, previously carried as buildroot patches, are running on three converted cameras.

Known, deliberately not in this PR

Netlink link dumps (RTM_GETLINK) oops this kernel in rtnl_fill_ifinfo() — dev in rtnl_dump_ifinfo's hlist_for_each_entry_rcu over dev_index_head is a garbage pointer. Reproduced with no vendor modules loaded (only lo and eth0), so it is in the base kernel + fh_gmac, not the SDK blobs — but it is not yet pinned to a line. The firmware side ships a /sbin/ip wrapper that avoids netlink for the common operations. Separate issue/PR once it is understood.

Before / after (Vatilon PB1, FH8856, GC4653; serial console)

Before — stock fullhan-fh8852v100 kernel on this board: fh_gmac finds no PHY (id 0x937c4024 unknown), eth0 never links; with SD1_NO_WP in the default pinctrl selection the SoC stalls in fh_pinctrl_init_devices() on pad 51 and the console is lost.

After — kernel built from this branch with only the tree-wide gcc-compat patches, booted from RAM against the OpenIPC rootfs:

PHY OUI: 0x937c4024 at phyid: 0
Linux version 3.0.8 (…) #2 Sat Sep 5 11:38:50 EEST 2026
Machine: FH8852
eth0 - (dev. name: fh_gmac - id: 0, IRQ #15
udhcpc: broadcasting discover
fh8856v100 login:

ping 0 % loss; tcp 22/554/8080 open; divinus reports chip=FH8856 sensor=gc4653_mipi. Zero oops. Kernel image 1750724 bytes, unchanged in size from the patched-in-buildroot build it replaces (1750732).

One commit; the three changes are described in its message.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Fix FH8856 V100 JL1101 detection, PHY reset, and SD1 pinctrl

🐞 Bug fix ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Recognizes JL1101 stepping 0x937c4024 and applies the existing PHY initialization.
• Preserves U-Boot's PHY state by skipping the unwired FH8856 reset GPIO.
• Removes unsupported SD1 pin muxing that hangs FH8856 V100 boards during boot.

Diagram

graph TD
  UBOOT["U-Boot PHY"] --> BOARD["FH8856 init"] -->|skip reset| GMAC["GMAC MDIO"] --> PHY{"JL1101 ID"} -->|4023 or 4024| MODE["PHY mode setup"] --> LINK["Ethernet link"]
  BOARD --> PINCTRL["Default pinctrl"] --> PADS["Safe pad muxes"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Disable the PHY reset callback

• ➕ Avoids retaining unreachable reset code after an unconditional return.
• ➕ Expresses through platform data that FH8856 has no usable reset GPIO.
• ➖ Removes the detailed hardware rationale from the reset function unless relocated.
• ➖ Could complicate future support for an FH8856 board with a wired PHY reset line.

2. Match the JL1101 revision with a mask

• ➕ Automatically supports compatible future JL1101 steppings.
• ➕ Avoids adding an exact switch case for every revision.
• ➖ The custom driver lacks an established PHY-ID mask mechanism.
• ➖ May apply register programming to unverified or incompatible revisions.

Recommendation: The PR's targeted board and exact-ID fixes are appropriate for this old vendor kernel and minimize regression risk. The only worthwhile refinement is assigning a null PHY-reset callback and removing the unreachable reset body, while retaining the hardware explanation nearby; exact PHY matching should remain until additional revisions are verified.

Files changed (6) +17 / -3

Bug fix (3) +14 / -0

board-fh8856.cSkip the invalid FH8856 PHY reset sequence +9/-0

Skip the invalid FH8856 PHY reset sequence

• Makes the FH8856 PHY reset callback return without toggling GPIO11, which maps to an unwired PWM7 pad on affected V100 boards. This preserves the working PHY state established by U-Boot and prevents MDIO discovery failures.

arch/arm/mach-fh/board-fh8856.c

fh_gmac_phyt.cInitialize the newer JL1101 PHY stepping +2/-0

Initialize the newer JL1101 PHY stepping

• Handles 'FH_GMAC_PHY_JL1101_B' in both RMII and MII mode switches. The new stepping receives the same page-7 register programming as the existing JL1101 revision.

drivers/net/fh_gmac/fh_gmac_phyt.c

fh_gmac_phyt.hDefine the JL1101 0x937c4024 PHY identifier +3/-0

Define the JL1101 0x937c4024 PHY identifier

• Adds a named identifier for the newer JL1101 stepping found on FH8856 V100 boards and documents its compatibility with the existing setup sequence.

drivers/net/fh_gmac/fh_gmac_phyt.h

Other (3) +3 / -3

board_config.fh8856.appboardRemove SD1 from the FH8856 appboard pinctrl defaults +1/-1

Remove SD1 from the FH8856 appboard pinctrl defaults

• Drops 'SD1_NO_WP' from the appboard's default pin groups. This prevents unsupported SD1 pad muxing from stalling board initialization.

arch/arm/mach-fh/include/mach/board_config.fh8856.appboard

board_config.fh8856.testboardRemove SD1 from the FH8856 testboard pinctrl defaults +1/-1

Remove SD1 from the FH8856 testboard pinctrl defaults

• Drops 'SD1_NO_WP' from the testboard's default pin groups, keeping its configuration aligned with supported FH8856 hardware.

arch/arm/mach-fh/include/mach/board_config.fh8856.testboard

board_config.hRemove SD1 from the active FH8856 pinctrl defaults +1/-1

Remove SD1 from the active FH8856 pinctrl defaults

• Removes 'SD1_NO_WP' from the active board configuration so boot-time pinctrl initialization avoids the conflicting SD1 pads.

arch/arm/mach-fh/include/mach/board_config.h

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. FH8852 PHY reset disabled 🐞 Bug ≡ Correctness

Description

The unconditional return disables PHY reset for FH8852 as well as FH8856, because both machines
share this board file and GMAC callback. FH8852 explicitly defines GPIO11 as its Ethernet PHY reset,
so its PHY may remain uninitialized or fail detection during boot.

Code

arch/arm/mach-fh/board-fh8856.c[420]

+	return;

Evidence

board-fh8856.c is compiled for all CONFIG_ARCH_FH8856 builds and declares both FH8856 and FH8852
machines using the same initialization. Its common GMAC platform data always installs
fh_phy_reset, which the MDIO reset path invokes; meanwhile, the FH8852 board configuration
explicitly documents and defines GPIO11 as the Ethernet PHY reset, proving that bypassing the
callback changes required FH8852 behavior.

arch/arm/mach-fh/Makefile[10-14]
arch/arm/mach-fh/Kconfig[118-136]
arch/arm/mach-fh/board-fh8856.c[411-447]
arch/arm/mach-fh/board-fh8856.c[1251-1267]
drivers/net/fh_gmac/fh_gmac_phyt.c[59-70]
arch/arm/mach-fh/include/mach/board_config.fh8852.appboard[15-24]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new unconditional return in `fh_phy_reset()` disables the hardware PHY reset for every machine using the shared FH8856 architecture code, including FH8852 boards whose configuration explicitly identifies GPIO11 as the Ethernet PHY reset.

## Issue Context
Keep the no-reset behavior for the affected FH8856 board configuration, but retain the existing GPIO reset sequence for FH8852 and any other configuration where the reset line is wired. A board-specific callback or compile-time board guard can provide this distinction.

## Fix Focus Areas
- arch/arm/mach-fh/board-fh8856.c[411-447]
- arch/arm/mach-fh/include/mach/board_config.fh8852.appboard[17-24]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can keep summaries lean with Finding overflow, which tucks the rest behind 'View more'

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. Fh8852 phy reset disabled 🐞 Bug ≡ Correctness

The unconditional return disables PHY reset for FH8852 as well as FH8856, because both machines
share this board file and GMAC callback. FH8852 explicitly defines GPIO11 as its Ethernet PHY reset,
so its PHY may remain uninitialized or fail detection during boot.

Agent Prompt

## Issue description
The new unconditional return in `fh_phy_reset()` disables the hardware PHY reset for every machine using the shared FH8856 architecture code, including FH8852 boards whose configuration explicitly identifies GPIO11 as the Ethernet PHY reset.

## Issue Context
Keep the no-reset behavior for the affected FH8856 board configuration, but retain the existing GPIO reset sequence for FH8852 and any other configuration where the reset line is wired. A board-specific callback or compile-time board guard can provide this distinction.

## Fix Focus Areas
- arch/arm/mach-fh/board-fh8856.c[411-447]
- arch/arm/mach-fh/include/mach/board_config.fh8852.appboard[17-24]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[kasperiio]

Good catch — thank you. board-fh8856.c is built for every CONFIG_ARCH_FH8856 machine, so that unconditional return disabled the PHY reset for FH8852 boards too, where board_config.fh8852.appboard documents GPIO11 as the EMAC PHY reset and the line really is wired.

Fixed in 856b5ae, using the compile-time board guard you suggested:

• fh_phy_reset() now skips the sequence only under #ifdef CONFIG_GPIO_EMACPHY_RESET_UNWIRED, with the original body in the #else — so it is compiled out rather than left as unreachable code after a return.
• The macro is defined in board_config.h, board_config.fh8856.appboard and board_config.fh8856.testboard, and not in board_config.fh8852.appboard. FH8852 is untouched by this PR.

Verified by compiling arch/arm/mach-fh/board-fh8856.o both ways against the same kernel config:

• With the FH8852 config (macro undefined) it builds and the reset sequence is present in the object — 8 gpio_request/gpio_direction_output calls.
• With the FH8856 config (macro defined) the object code is byte-identical to the build already running on the three cameras, so the hardware evidence in the description still stands unchanged.